Product Management Software and Tools Archives

Tag Archive for: Product Management Software and Tools

Application lifecycle management (ALM) tools enable efficient, standardized communication and collaboration between teams in application development, testing, and other business departments. The benefits of a top ALM platforms include less risk from manual and siloed application lifecycle management processes, plus superior confidence in the outcome of compliance and product quality.

What is application lifecycle management?

ALM itself is a broad term. It encompasses key activities across requirements management, quality assurance (QA), IT service delivery, and project management. By spanning all of these diverse activities, ALM may include every workflow from mapping out a preliminary route to regulatory approval for a software-driven medical device, to the testing of that same product in alignment with its requirements and its eventual post-release maintenance.

The exact structure of ALM, and the particular solutions selected to support it, will vary based on the software development practices in use at an organization. For example, ALM can support Agile methodologies as well as DevOps automation processes built around continuous integration and deployment pipelines. In these instances, an integrated ALM process, backed by the right ALM platform, helps bring teams together and ensures all requirements are met for each application.

Application lifecycle management tools can also work within Waterfall methodologies in which activities are broken down into discrete stages instead of approached continuously. Process-agnostic ALM platforms may be configured to support a variety of software projects and extended to support hardware initiatives that revolve around product lifecycle management (PLM), too.

In fact, ALM first emerged as a software-specific evolution of PLM, which applies to physical products such as automobiles. Organizations may seek integration between their ALM and PLM process and technologies to maximize the efficiency of their development processes, such as in the case of a complex connected device within the Internet of Things (IoT).

What do application lifecycle management tools do?

At a high level, best-of-breed modern ALM platforms may provide tools for:

Requirements management

Traditional processes for managing requirements are outdated, as they often involve maintaining numerous Microsoft Word documents and/or spreadsheets, all of which may need to be developed and reviewed separately. This approach slows down the application lifecycle while increasing costs by introducing unnecessary risk related to human error.

In contrast, an ALM tool form offers a comprehensive solution for requirements management. Teams can define all requirements, risks, and tests, plus create virtual relationships between work items, perform risk analysis, and have easy visibility into the potential impact of making changes. Requirements can be scheduled and managed from one interface.

Essentially, the ALM platform serves as a single source of truth where costly rework and time-consuming reviews of multiple siloed data sources can be avoided. Meanwhile, development processes are typically accelerated through substantial reductions in the time needed to identify and remediate requirements-related defects.

End-to-end activity traceability

With applications being developed on increasingly fast timelines and in accordance with a growing array of requirements and regulations, traceability is crucial.

Are development and testing activities adequately fulfilling all defined requirements (on both general and granular subsystem levels)? Are there any gaps in test coverage? Can proof of requirements fulfillment easily be reviewed, signed, and used to demonstrate compliance?

Getting reliable answers to these questions and others requires a capable ALM platform. The right ALM platform provides solutions for creating virtual trace relationships between requirements, risk, tests, and other development activities. More flexible ALM platforms can be extended through toolchain integrations (see below) to capture activity traces across teams and platforms. Virtual traces also tie electronic signatures to any defined milestones and released documents, as well as provide a way to see and analyze the potential impact of making changes. Proof of requirements fulfillment (i.e. trace views and matrixes) should be easy to monitor and export to demonstrate compliance.

Software testing and QA

Testing is an important part of ALM. More specifically, test results will need to be continually updated to accurately reflect the progress of an application’s lifecycle.

Keeping track of these details is more practical with a modern ALM platform that makes it easy to see the status of existing test results, add new tests as needed, and perform time-saving batch updates that capture or change the status of multiple test executions, all in one repository

With the right application lifecycle management tools, these testing and QA processes can be greatly streamlined by providing teams greater visibility into the requirements that inform their work. Accordingly, teams can get the most from their Agile processes and deliver the highest quality software to market as quickly as possible.

Real-time team collaboration

ALM is a fundamentally collaborative endeavor, as it spans a wide range of activities from project management to QA. But efficient collaboration can’t be taken for granted – teams need intuitive collaboration technologies to keep their work aligned and on track.

The real-time collaboration capabilities in an ALM or ALM-adjacent tools enable productive reviews and approvals. Features such as virtual reviews and electronic signatures containing a complete timestamp provide structured solutions for distributed/remote teams to streamline collaboration and ensure compliance with regulatory standards.

Feedback can be captured in one place, allowing for items to be quickly and efficiently categorized as approved or in need of work. Centralizing collaboration features with requirements management provides a solution to track which stakeholders are involved so that follow-up actions can be appropriately assigned as necessary. Moreover, it reduces the risks associated with protracted project times and personnel churn, as knowledge it retained in the system itself rather than in individual minds, making key insights readily available down the line.

Toolchain integration

Multiple platforms may be combined to handle all of the different aspects of ALM-PLM. Platform extensions are typically constructed through built-in integrations or through the use of open APIs that support custom work.

The integration of platforms is important to keep activities, such as software development, properly aligned with requirements. An ideal integration allows for essential information to synchronize between platforms, facilitating collaboration, and improving visibility across otherwise siloed teams and/or technologies. In many cases, a toolchain integration offers a solution for improved traceability to demonstrate compliance.

Testing tools, task, and bug tracking software, and automation servers have great potential for integration with application lifecycle management platforms. Overall, an integrated ALM toolchain will lower risk and lead to better quality and compliance. The integration between Jama Connect and Jira is a prime example of how pairing different best-in-class platforms can increase visibility and support the work of global teams.

To learn more about Jama Connect, visit the main product development page, or get in touch with a member of our team.

To learn more on the topic of requirements management, we’ve compiled a handy list of valuable resources for you!

SEE MORE RESOURCES

At a conference I attended recently, I listened to teams discuss the challenges they faced in deploying software in their organizations. The consensus was that the software is easy; the people are hard. That is to say, getting up to speed with a new software solution itself is relatively easy compared to getting people to change their behavior and successfully adopt new software.

ROI Requires that Teams Actually Use the Solution

One of the speakers said something that really stuck with me. This person said, “There is no return on investment without adoption, and there is no adoption without user acceptance.” And while that may seem obvious, many times the end user of the software is forgotten. Other priorities — like budget, schedule, and various agendas — put a lot of pressure on the deployment plan. The human aspect, as important as it is, gets lost.

Gaining Acceptance Later in the Implementation Will Cost You

When implementing a new solution, it’s imperative that you get your team on board from the get-go – and not just for the purpose of keeping them happy. Just as it’s more costly to identify inaccurate requirements late in the product delivery lifecycle, the same principle holds true for user acceptance. Resistance from users identified late is always going to be more costly than adoption issues identified and addressed early.

While implementing a new solution may be a top–down decision, it’s important to remember that the users are the ones who will need to adapt to the change. The primary impacted stakeholders (i.e. the end–users) will be more receptive to a major change if they are participating in the process, rather than being told that they must adopt a new tool. 

Change is difficult, and without a full understanding of the benefits of a new solution, teams may feel frustrated or resistant. One way to preemptively combat resistance is by identifying long- and short-term goals for each team member and encouraging users to be involved in the implementation process.

The Key to User Adoption is People

Having worked in professional services for over a decade, I have come to see just how valuable it is to understand the people side of deployments. In my years as a business analyst, I’ve seen from the inside just how difficult it can be to get people on board with new solutions, particularly those that also come with process changes, and how to make those changes stick.

My interest in this topic goes even deeper. A few years ago, I completed a master’s program in psychology where I studied human behavior and why people do or do not change. I’ve found that what I learned during my study of psychology has translated quite well to the consulting world.

In this post I won’t be able to outline the perfect adoption plan for your organization; this would be futile as no two companies have the same needs or challenges. But I will discuss the approach we recommend when planning for a solution rollout that maximizes adoption.

If You’re Taking a Trip, Bring the Whole Team Along

I’m going to start with an analogy:

Let’s say you’ve pretty much determined that everyone on your team could benefit from a vacation. You’ve even heard people say so. You’ve had some good conversations about what people want and need, and with that knowledge you pick out a destination that’s going to recharge everyone.

Next, you have to figure out what kind of transportation you’re going to use to get everyone to the identified location. You’ve gone online and talked to some others about what kind of vehicle works best for teams like yours.

So, with the information you have, you go ahead and buy the perfect car for this trip. It has all the things you need.

In case you haven’t figured out how the pieces of my analogy fit into the rollout of a new solution, here it is:

The people are those who would benefit from a new process and solution to meet their business objectives
The “destination” is that ultimate goal, where the benefits are realized
The “car” is the new software solution that gets you to that ultimate goal

But here’s something you have to consider before you embark on this journey: You have to figure out where everyone lives, what kind of baggage they’re bringing with them, and how you’re going to organize picking them all up so you can all be in the car at the same time, happily enjoying the journey to your destination. More on that in a bit.

Key Factors in Planning a Successful Software Deployment

If you’ve ever actually planned an out-of-town experience with coworkers (or family, for that matter), you know it’s impossible to make everyone happy all the time. Introducing a new way of working to your teams can be even more difficult. Why?

Before I answer that, remember that these are the main things to keep top-of-mind when planning a successful deployment:

Bringing new teams into a new solution, with new processes, is not simply a functional or technical issue; it is a people-centric change.
Benefits that require that people adopt the solution inherently require that those people change behavior.
The longer adoption problems go unaddressed the more difficult and expensive they are to address.

New data for 2019 reveals the growing gap between product complexity and requirements management. Find out more by downloading our report.

Design Your Approach Based on the Specific Needs of Your Team

Change is hard – especially when people are involved. You can put up your pie chart or line graph with anticipated benefits and have everyone nodding their heads in agreement, and you can find the perfect “car” to get you there. But you cannot assume that pointing at that amazing vacation spot on a map or showing off your awesome new vehicle will translate to motivation and acceptance for the people who must be on board in the end.

Of course, some will be on board immediately, so make sure you identify those people and train them to evangelize for the effort. These advocates are a great asset as you complete your rollout to the rest of the organization. Successful organizations often pair these early adopters with new users to help them get up to speed with the new process.  

Others may need more attention, and you must pay careful attention to their fears and objections and speak to them early and often.

Consider the Delta Between Where Your Team is Today and Where You Want to Be

You must consider the maturity of your organization and teams. Of course, it doesn’t have anything to do with the emotional maturity of the individuals (though that could come into play), but the maturity of their processes and toolset and how they’re accustomed to getting their work done today. In my experience as a consultant, I find that team maturity ranges widely, especially when it comes to requirements management processes and supporting tools.

Knowing where teams are — or their level of maturity — is important for a number of reasons, not least of which is anticipating resistance. Think about the person who is currently using a Word doc that they keep somewhere on their laptop to manage the requirements for a really complex product. This might be considered a pretty basic level of maturity.

Now, before bringing this person into a new solution, it is important to think about the degree of change being asked of this person. What does a single-source collaborative system feel like to a person coming from Word files on their computer? What resistance can you anticipate and what will be your approach? Again, communication early and often is going to be key to getting this person on board with a new solution.

Learn more about best practices for change impact analysis by reading our blog post.

Engage with People to Counteract Resistance

When change is introduced, the initial reaction from most is to resist. This isn’t necessarily a bad thing, as not all change is good. But if you don’t address resistance, it can lead to rigidity, causing teams to dig their heels in and get stuck.

When you are bringing on a new team into your deployment effort, don’t just set up training on how to use the tool. You’ll want to engage with your people at a personal level so you can uncover their anxieties and address them. You’ll need to anticipate their questions and welcome their concerns. When you know their concerns, you can address them; it’s the concerns you don’t know about that can manifest very late and cause problems for the whole deployment.

For example: Consider a person who has yet to log into the software even a month after deployment. What did we not know about this person that let them slip through the cracks? A quick way to find out is to simply ask them.

Remember that unanswered questions today turn into resistance tomorrow. Provide opportunities for people to voice their questions early so you can address them. Consider establishing clear channels for communication with users.

Explore product development strategies for systems engineers by downloading our whitepaper.

Adopt a Change Management Model to Give Your Project Structure

There are many change management models out there, and I recommend researching these until you find one that make sense for the size of your company, its culture, and your strategic goals. I personally like the ADKAR model from Prosci.

The five parts of this specific change management model fit well with how we’ve been discussing bringing on teams to improve adoption:

Awareness of the need for change.
Desire to participate and support the change.
Knowledge on how to change.
Ability to implement required skills and behaviors.
Reinforcement to sustain the change.

We’ve also seen great success from teams who have read this book: “Change Management: The People Side of Change,” by Jeffrey M. Hiatt and Timothy J. Creasey.

A good change management model, like ADKAR, will help you consider the approach you want to take as you get started on your deployment plan. You’ll want to think about:

How you will build awareness, not just of new processes and solutions, but also why you’re taking on this initiative and what you hope it will do for your organization.
How you will communicate the benefits of using the solution, particularly the “what’s in it for me” for each individual or each team.
How you will build knowledge about how the solution works, relative to the current tool, and how to get the most of it.
How will you ensure people gain the ability to use the solution with the proper training for their position, in a style that will help them feel empowered and not burdened through the learning curve.
What kind of reinforcements you can use to ensure that the process change sticks and the initiative’s objectives are met.

These are just a few examples of how to use the ADKAR model but the key is to engage with this line of thinking early and be open to adjusting as you learn more.

To learn more, watch our webinar to learn about other best practices for implementing new technologies.

On a chance bus ride down MLK to our Jama office a few months ago I happened to share a seat with a colleague in our Engineering Department, Bryant Syme. He had only been working for Jama for a few months and to be perfectly honest I hadn’t spoken to him much yet. We talked a lot about recent events in the office, but also talked about some of his previous work experiences. This is the first time I had ever heard about Mob Programming and the many potential benefits it can bring to a team of engineers. It planted the seed for me to introduce it to my own team and eventually start evangelizing it to the rest of our department.

What is it?

Mob Programming is a style of paired programming, but with the entire team involved instead of two developers. Every person involved in the story should be in the Mob Programming session and actively contributing, including Product Managers, DevOps and QA Engineers.

Think of Mob Programming as a tool for getting through larger, more obtuse stories and epics. The team will crowd around a single screen with one person driving and will talk through everything from acceptance criteria and design decisions, to implementation of the code and even test cases.

Mob Programming has many benefits:

Shared ownership over decisions.
Better quality code.
Ability to break through large tasks easily.
Team bonding through working together.
A great way to teach other team members various skills.

This style of work doesn’t need to be limited to programming. It could also be great to work on any project, from writing a document to planning for future work, to doing performance testing.

The tenets of Mob Programming

The main tenets of mob programming that everyone should follow are:

Use one keyboard and screen
Use a private room
Select a time keeper to rotate who is on the keyboard every 15 or 30 minutes.
Everyone gets time at the keyboard, even non-programmers.
Take a story from start to finish, or in other words: from planning to coding, to testing, to done.
Take breaks when you want.
A session should span an entire workday.

Each of these tenets are flexible and should be discussed with the group before starting. One thing I’ve had a lot of luck with so far is pausing the timer to do whiteboard planning, for instance. We also usually take however much time we need at the beginning of the session to sketch a rough plan of what we are going to do, in order to stay on task as people switch around.

One keyboard and screen

This allows the team to concentrate without the distraction of e-mail, chat applications or other work. Team members may come convinced that they will need to work on other activities since there won’t be enough to help with when they aren’t at the keyboard. I had such an encounter with one of my teammates who was certain that there would not be enough for him to do. You will need to remind them that this is not a normal meeting and that you need their full attention. In the case of my teammate, I conceded that he could bring his PC as long as he kept his attention on the task at hand. He agreed and ended up being so engaged that he rarely, if ever, looked at his own screen.

One rule you can bend here is that research on one screen can be boring for the team to watch and help with. This is an appropriate time for other team members to use their own PCs to help do research (as long as everyone is staying on task).

Use a private room

This moves the team to another space both physically and mentally, and also prevents outside distractions. Other teams should respect that you have shut the doors and should not interrupt you. But if you are interrupted, team members should volunteer to chat with that person outside of the room to allow others to keep working.

Rotate who is on the keyboard every 15 or 30 minutes

Decide on a good time interval at the beginning of the meeting. I recommend 15 or 30 minutes depending on how many people are in the group, but other time increments are also fine. I’ve found that a group of 4 or less people works best with 30 minute intervals, wheras 5 or more works best with 15 minute intervals. Its just enough time to get some work done, but also enough for everyone to rotate through in the large group.

Bring a timer with a loud alarm. I usually use the Clock App on my iPhone and turn the sound way up. When the alarm goes off, whoever is at the keyboard should immediately take their hands off and let the next person rotate in, even if they were in the middle of typing. The thing to remember here is that it’s not about one person working while the others watch, as it is about everyone working on the same thing. Whoever else rotates in should easily be able to pick up where the last one left off.

A clock that resets itself is also ideal, since you don’t want to forget to start the timer.

Everyone gets time at the keyboard, even non-programmers

Whoever is helping should have a chance at the keyboard, even if they are in a QA, PM or DevOps role. Remember that everyone is working on the same task and watching and directing what the driver is doing, and it should not matter much who is on the wheel. It’s ok to be a backseat driver in this situation.

Participation also keeps everyone at full attention! Keeping the same person or only developers will become boring for others in the room if they never get a chance to participate.

Take a story from start to finish

Even when coded, the story isn’t finished, it still needs to be tested! Work on your test cases as a team. Personally, I am a QA engineer and getting other team members to help work on making quality test cases is very validating and helps us be less black box.

Whatever is required to get that story into the “Done” column should be done during this session. In addition to getting higher quality code, test cases and automation, this also tears a lot of walls down between roles. A lot of our developers often don’t have much of an idea for what DevOps or QA engineers “do”. This is a perfect chance to get cross-team collaboration and boost how your team works together!

People are allowed to take breaks when they want

Bathroom breaks, coffee breaks, lunch breaks should not be discouraged, but be warned: people will want to keep working, so mandatory breaks may be needed!

Mob programming can also be exhausting, if someone needs a few minutes to take a breather, they should be allowed to simply leave and come back when needed.

A session should span an entire workday

This one has been difficult to schedule a lot of times. So far we have managed to schedule one full day and several half days of mob programming. Most literature I’ve seen on the topic so far recommends the full day, if possible, though. If individuals need to leave for meetings or other commitments, there should still be enough people left to absorb their absence.

Conclusion

Mob Programming is a great tool that can be used to effectively chop down and complete large stories and epics. Remember if you are trying this, review the tenets with your group, such as sticking to one screen and one keyboard, as much as possible.

This is also great for bringing other team members up-to-speed with certain design patterns or tools. Someone who never uses the command-line or has never dealt with a certain language before will likely get a chance to learn a lot.

Everyone in the room should be involved, don’t limit it to just programmers, or others will get bored and not be as engaged. Remember to invite everyone in your team to the session, including the Product Managers, QA and DevOps Engineers.

And of course remember to have fun! Odds are your team will have a blast and work just a little better together than before the experience.

VPs of Product shoulder a formidable set of full-time challenges. Accountable to both business and engineering plans, a wise Product leader recognizes that clear communication and meaningful collaboration are a means to an end, and therefore matter as much as the goals.

Whether you’re managing performance and production with Agile, Scrum, Waterfall or a hybrid development methodology, dealing with obstacles and priority changes leaves you little time for error or waste. One overlooked production error, miscommunicated change in requirements, or delayed decision can, at best, increase the number of iterations and the production cycle.

When you oversee product development you’re also, in a way, overseeing people development, because people build products. And because people build products, it makes sense that the tools your people use must be built with an understanding of how people work together.

Whether your primary concerns are for traceability, requirements engineering and management, or enabling shared reviews of action items to ensure team alignment, if your product tools aren’t intuitive for engineering and business users, those tools won’t get used.

Choosing the right product development tools is a serious matter, because as a VP of Product, you have so much riding on building right and moving fast:

Tall tasks:

Approving project plans, setting high-level product strategy across multiple projects and initiatives, ensuring that projects properly support strategic initiatives, and managing Profit and Loss.

Pressure points:

Lacking visibility into key decisions that affect schedules, progress and outcomes.
Struggling to find evidence that teams are building the right things that will deliver value to the customer.
Avoiding detail overload.

Burning desires:

To establish a high-level view of the entire portfolio of projects in order to quickly asses scope, risk, change and progress.

With Jama, VPs of Product can turn awkward “Growing Pains” episodes into agile “Greatest American Hero” epics.

How so? You’re able to…

Keep the entire team aligned with the strategic goals of the organization.
Gain greater visibility into what’s being built to ensure the product delivers on business value.
Communicate easily with the entire project team to get clarification and decisions made, regardless of location.
Ensure faster times to market.

Read Game Changers Who Play to Win: Omnigon to see a real-world example of the ways Jama can help VPs of Product stay on top of the product development game every step of the way.

Check out other ways Jama helps business and engineering teams get and stay aligned:

How Jama Helps VPs of Sales

How Jama Helps Systems Engineers

How Jama Helps QA Leads

How Jama Helps Project Managers

How Jama Helps Business Analysts

How Jama Helps Product Managers

Stop chasing down documents in DOORS and focus on the items within them that matter.

For many years, IBM’s Rational DOORS (v.9) has been a widely adopted Requirements Management (RM) tool for teams working with high-compliance systems engineering programs. Because it’s often sold into the enterprise as part of a larger IBM suite, its widespread use is sometimes a matter of default rather than choice.

If you’re like most of today’s systems-driven engineering organizations, you’re primarily in the business of producing complex, ﬁnished products and components, often involving a mix of hardware, software and ﬁrmware. You’re probably also in a hybrid-Agile development environment and figuring out how to scale that effectively.

In business, times change because needs change. Changes driven by the rise in software-driven products, the imperatives of on-time delivery, and extended supply-chain systems threaten to disrupt traditional, legacy manufacturing and engineering processes. Your teams are pressured to accelerate product delivery and manage growing complexity in distributed organization and supply chains, within products, and across a network of interrelated and interdependent products.

Jama is built to serve and evolve with the ways systems engineering teams build products. How is it different? Jama deconstructs documents into actionable items. You can easily see, grab and reuse items, and be confident that they’re current and include all related comments and status. Forget about wordy “reading assignments.” You can share specific work components with your team for review and approval, without the risk of compromising security or access permissions that document shuffling causes. And when it’s time to pull it all together again to submit or archive a controlled document version, Jama can do that, too.

Skeptical? Make us prove it to you. Sign up for a free 30-day trial and give us a shot. No installation required.

And one proven way to handle them with speed and finesse.

For product managers and their counterparts, the road to launch is a fight to keep every task, every detail and every change grounded in business goals. It’s not enough to be fast. Or to deliver the right product. You need to do both. Yet, the tools product managers depend on are often the weakest link, and not up to the tasks of fast-paced iterative development. But whatever product management tools and methodologies you’re using, you’ll still need to tackle these 10 challenges:

Engaging all the right stakeholders in the most effective, efficient manner (knowing who to involve, when and how)
Tracking product, program and project details while responding to a constant stream of new information
Finding critical information you need at the moment you need it instead of searching through emails, spreadsheets, SharePoint, tribal knowledge in team members’ heads, etc.
Keeping teams in-sync and updated on what they are planning, building, testing and releasing
Prioritizing and re-prioritizing what goes into each release, based on new information, insights and pressures from multiple voices—everyone from front-end users to engineers to sales to support
Revisiting decisions and changes because you haven’t been able to capture context, discussions or approvals in an accessible manner
Identifying opportunities to reuse and synchronize projects, items and components to reduce risk and save time
Navigating and mastering the complexity of products, projects, processes, teams and communication
Struggling to delight business customers while juggling overtaxed resources and tight deadlines
Ensuring on-time, within-budget delivery of the right product

Check out The Product Delivery Problem (It’s Not You) to uncover the one surefire way to establish and maintain a strong connection between intended outcomes, development methodologies and customer value.

Do you have any particularly problematic product challenges not listed here? Share what’s on your mind in the comments or send us a tweet and read our next practical product management and development post here.