by Enfocus Solutions | Apr 1, 2014 | Collaboration, Product Development, Uncategorized |
For Part 1: Easy to Talk About, Much Harder to Achieve, read previous blog post The question of when teams need to collaborate in the product development lifecycle has an easy answer: always. But, there are key activities that take place within a product development lifecycle where collaboration is absolutely necessary. Collaboration through Product Discovery and Product Delivery There is an emerging concept in product management called dual-track agile that essentially looks at product development as two tracks: the product discovery track, and the product delivery track. On the product discovery track, teams collaborate to understand what the right product is to build. On the product delivery track, teams collaborate to make sure the product is built right. (Source: Jeff Patton, www.agileproductdesign.com) Both tracks require a foundation of collaboration and validation in order to be successful. In today’s blog post we’re going to talk about the importance of collaboration through the product discovery phase of product development—when teams are trying to figure out ‘what’ actually needs to be built in order to be of value to the market. Traditionally, in the product development lifecycle the validation of a product doesn’t tend to happen until after the launch of a product or during the validation of a developed prototype. Usually by that time, a significant amount time and money has already been spent on defining and developing the product to some degree—without completely validating that the product will meet a market need. On the product discovery track of the dual track agile approach, the focus is on validation, validation, and validation. Validation that the right problem has been identified, validation that...
by John Parker | Mar 31, 2014 | Business Analysis, Project Management, Uncategorized |
Simply put, cloud computing is computing based on the Internet. In the past, people ran applications on a physical computer or server in their building, cloud computing allows people access the same kinds of applications more easily and anywhere through the Internet. Cloud computing is growing rapidly because it just makes economic sense. So why are so many businesses moving to the cloud? It’s because cloud computing increases efficiency, helps improve cash flow and offers many more benefits. Let’s explore some of these benefit: Automatic software updates Many organizations that have implemented an on-premise ERP or CRM system know how painful it is to upgrade the software. With Cloud computing, updates are applied automatically — this is part of the basic service and often saves organizations millions of dollars per year. This frees up customers’ time that can be used on other important tasks. Flexibility The Cloud provides much more flexibility for increases and decreases in demand. For example, if a company needs more bandwidth than usual, maybe for some special promotion, a cloud-based service can instantly meet the demand because of the vast capacity of the services’ remote servers. In fact, this flexibility is so crucial that 65% of respondents to an InformationWeek survey said “the ability to quickly meet business demands” was an important reason to move to cloud computing. New users can be added or removed very easily adjusting to business demand as needed. Disaster recovery Disaster recovery is often much easier for cloud based services as this capability is a standard part of the service. Cloud computing providers take care of most issues, and they...
by Enfocus Solutions | Mar 27, 2014 | Collaboration, Product Development, Uncategorized |
We’ve all heard about collaboration, talked about collaboration, and probably even agreed that collaboration is really really really important—problem is, it seems much easier to talk about than to actually achieve. One of the key roles a product manager can play in any organization is to bring people together—to bring customers and users together to understand what their problems are and how to best solve them, to bring internal stakeholders together to understand what products will best serve the organization, and to bring the individuals of a product team together to work synchronously towards launching a valuable product that will delight their market and upset their competitors. But the fact is, it’s really challenging to get people harmoniously working together—and just as hard to keep them doing so throughout the entire product development lifecycle. As humans, we are all inclined to fulfill our own needs first—but when it comes to collaboration, those inclinations need to be shifted towards each individual working to fulfill the needs of an entire team before their own. If you’re thinking it sounds like hard work then you’re right—fostering collaboration during the product development lifecycle is indeed hard work. But it’s hard work that pays off. It’s currently estimated that 70-90% of all new products fail. You wouldn’t be alone if your initial reaction to that number is ‘wow!’ It seems like too high of a number—and one that makes launching a new product seem like a pretty bleak undertaking. But if we look at the leading cause of failing products then we might see that there is hope for a solution: the number one...
by John Parker | Mar 14, 2014 | Business Analysis, Project Management, Uncategorized |
Normally, trends and projections come out in December or January. These are a little late, but at least they still make the first quarter in 2014. Here are my predictions of key trends that we will see affect business analysis and project management in 2014. 1. Agile Continues to Grow – Agile adoption will continue to grow. This will mean many changes in terms of how requirements are developed and managed. Requirement “shall” statements will be replaced with user stories. The three C’s model of users stories: Card, Confirmation, and Conversations will continue to grow. PMs and BAs will continue to redefine their roles in the agile world of self-managing teams and product backlogs. 2. Managing Data not Documents – As agile adoption continues, the need for large paper based requirement documents will go away. Requirements will be managed as data in a backlog, not as long paper-based business requirement documents (BRDs) or Functional Requirement Specifications (FRS). 3. Dual-Track Agile Takes Off – Agile will be difficult and a cultural challenge for many organizations where there are multiple teams and resources are not collocated. “User story hell” will become a reality for many organizations as teams continue to spend more and more time grooming the backlog. Many organizations will adopt dual-track agile or some variant to better manage discovery activities. This will enable lower costs as requirements will be validated using less expensive methods than code. 4. More Emphasis on Business Change – The BABOK Version 3 will be released sometime in 2014. There are big changes coming to the role of business analysis. The focus will be much...
by Enfocus Solutions | Mar 12, 2014 | Business Analysis, Product Development, Uncategorized |
I was recently reading an article about a company featured in Fast Company magazine, who has become very successful with a very simple business model: give customers only what they want. You might be thinking: “well, that’s what every company does.” But, the 2013 Chaos Manifesto published by The Standish Group presents a very different story. They report that only 20% of any given product’s features are used often, 50% are hardly ever used, and the remaining 30% are used infrequently. Yikes. That literally means that about 70% of the functionality most companies are spending their money to discover and deliver to the market are not really even being used—and by extension, one can assume, needed. As a consumer I know I can relate to that—I’m pretty sure my phone does much more than I ever use, know how to use, or care to use. You can probably relate. But this company I was reading about in Fast Company, they didn’t really seem to have that issue because either a) they did not build anything not explicitly asked for by the market, or b) they quickly tossed any products that were not being used and moved onto research what else to develop. Now maybe that in and of itself is not that interesting, but what I did find interesting was they approach they used to do it. And how easily they seemed to have done it—as well as how cheaply. Some organizations spend thousands of dollars a year on market-sensing activities trying to figure out what the right product and features are to build—focus groups, surveys, market research service...
