Collaboration: Easy to Talk About, Much Harder to Achieve (Part 1)

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...

A Dire Warning for Business Analysts

In the most recent VersionOne State of Agile Survey released in 2014, Business Analysts are considered the least knowledgeable about Agile.  Please see the diagram below. Working with many Business Analysts, I am not surprised by this statistic, but it does concern me. In the Scrum world, there is no official role for a Business Analyst. We don’t write the functional requirements the way we did in the past and a Business Analyst is not required or needed to write or draft user stories. Business Analysis skills are very much needed, however the traditional BAs that simply write functional requirements will either need to re-skill or retire. Recently Forrester research shows that more than 90% of organizations are actively pursuing Agile. If Business Analysts do not learn and embrace Agile now, and they plan on continuing writing functional requirements in the ways they have in the past, then they should start planning a new career as their positions will soon be eliminated in a future downsizing effort.  If the BAs in your organization have not made the transformation to Agile, please call us at Enfocus Solutions; we can help.  We can provide you with the education, knowledge, and tools to transform you business analysis function to the Agile world.  Please attend the Webinar tomorrow to find out more. [cta...

The CIO/CMO Divide: A Guide for Project Managers and Business Analysts

Lately, Marketing has been purchasing a significant amount more of marketing-related technology and services using their own capital and expense budgets. Some of this purchasing is being done outside the control of the internal IT organization and some is being done in conjunction with IT. Gartner has made the bold prediction that by 2017, the CMO will spend more on IT than the CIO. Let’s look at some of the facts from the Gartner 2013 US Marketing Spend Survey: The average percentage of revenue spent on marketing is 10.4 % Digital Marketing represents 1/3 of Total Marketing Spend Up to Half of all Digital Marketing is Outsourced Search Marketing topped the CMO’s list of Outsourced Activities Over 40% claim that the keys to Marketing success are 1) Corporate Web Site, 2)Social Marketing, and 3)Digital Advertising Now, let’s look at some trends of why marketing is spending more and more on technology. First, we are living in the age of the customer. Customers now have real-time information about pricing, product features and competitors. As a result, they hold the advantages, and one of the few competitive advantages remaining for businesses is to concentrate on the knowledge of and engagement with customers. Josh Bernoff, a Forrester Research analyst stated in a recent report that companies must not only be customer focused, they must be customer obsessed, focusing their strategy, energy, and budget on processes that enhance knowledge of engagement with customers. Implementing a customer based strategy falls under marketing for most companies. For the last 10 years, many organizations focused on Customer Relationship Management (CRM).  Now the focus is on marketing...

Business Analysis and Project Management Trends in 2014

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...

Customer Needs: Come Out, Come Out, Wherever You Are….

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...

Rescuing a Troubled Project

According to the Standish Group, over 60% of projects fail or are challenged. Gartner Group 2011 research shows the same story; only it paints a slightly worse picture. Based on these statistics, program/portfolio managers and PMOs need to have skills for rescuing troubled projects. Determining if You Have a Troubled Project It is important to determine if you have a troubled project before any significant intervention is taken. It is best to do this using predefined criterion that are administered at the PMO or portfolio level. The following criteria provide  some examples: Project Planning The project does not have an agreed upon vision and clear set of objectives. Impacts that the project will have on the business architecture have not been identified and defined. A thorough stakeholder analysis has not been performed. Discovery The solution scope has not been clearly defined as a set of features that can be delivered independently. Customers and users are not adequately engaged in project discovery activities. Delivery Delivery team satisfaction is low. Agile team commitments have not been met. Velocity is decreasing. Project Performance The  project  is  trending  20%  or  more over  its  estimated  budget. The  project  is  trending  20%  or  more over  its  estimated  deadline. Benefits Realization   The  client  is  extremely  dissatisfied with  the  performance  of  the  project team. Benefits as defined in the business case are not being achieved. Project Recovery Process Turning around a troubled project is never easy, but there are approaches that can be used that provide a good chance for success.  It is important to note that success may not mean delivering the project within the original time and budget constraints. Rather the focus must now be on salvaging the project to ensure that the project addresses the business need and achieves the expected business outcomes. If...