DownloadProduct Fact Sheet

Subscribe via E-mail

Your email:

About our Blog

The Enfocus Solutions Blog is focused on helping organizations improve their requirements development and management practices. 

Read posts by our blog authors:

Add to Google Reader or Homepage

Business Analysis & Requirements Management Blog

Current Articles | RSS Feed RSS Feed

Collaboration: Working together through Product Discovery (Part 2)


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,

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 the right solution has been decided upon, and validation that the solution being proposed is a beneficial opportunity for the company to invest in. Validation cannot be done without collaboration.

Remember that statistic we mentioned the other day? That 80% of a product’s features are never or infrequently used? Well here’s another stat to think about—of the billions of dollars in consumer electronics that are retuned annually, only about 5% of those are because of defects. And what that really says is that the main reason people are returning products is simply because they are not what they expected or needed.  And it’s not just because they were unwanted Christmas or birthday presents. Returning a product because it is not what we needed is something we can all probably relate to—how many of us can say that every product we have purchased has met our needs perfectly? Or that we have never returned a product once purchased because once we got it home ‘it was way more complex than it needed to be.’ People want products that solve their problems and are easy to use—in other words, they want usability and utility.

Product discovery helps us develop products that will solve a real problem—and make sure the features we do develop are meaningful and valuable for the target market. And that’s because the product discovery track’s entire purpose is to eliminate all potential product features that will not solve real market problems. In the world of lean, it means that we are eliminating the ‘waste.’

How does product discovery work?

During product discovery, validation is the name of the game—and in order to validate, you need to collaborate.

The right market problems need to be identified and validated. 

There is no value, or business sense really, in developing a product that solves a non-existent problem. It’s a lose-lose situation—the market gains nothing and the company developing the product could possibly lose everything. 

One of the key activities within the product discovery phase, and one that almost every product manager is responsible for, is to ensure real market problems are being identified to solve. How to identify the problems can be the tricky part—the list of potential problems can sometimes seem endless and the effort to sift through them all to identify the real ones can often seem overwhelming. There are problems reported directly from existing customers in the form of complaints, there are direct requests for new features from existing customers, the request for new products from potential customers, the market studies that indicate the need for this or for that for market segment x or market segment y—you get the picture and most likely relate. Identifying the real problems to solve can be a daunting task. But if it’s not done and the right problem is not defined then there can be an entire domino effect into the solution that is eventually defined, then developed, and then released—most likely into a market that will not want it.

The source for gathering problems can be many in product management: specific feature requests from existing customers, product requests from potential customers, focus group results, market studies, customer interviews, user conferences, and the list can really go on.  But receiving problems and understanding what problems need to be resolved in order to be of value to a customer is a different ball game.

We have all probably heard the famous ‘horses’ quote by Henry Ford:

 “If I had asked people what they wanted, they would have said faster horses.” 

Whether or not that statement is actually accurate, we cannot be sure—but I think the point of the quote is important and valid. And that is: the problems we receive from our customers are not always the problems that need solving. They are however, problems that need analyzing. Many times what we receive from customers are the symptoms of the real problem or a solution they have already thought up in the form of a feature request—the product discovery team then needs to take those problems to analyze them, categorize them and identify where the patterns lie—and what the real problems are that need solving. To do that effectively (and efficiently) requires validation through collaboration. Problems need to be analyzed from different perspectives, and everyone on the team needs to be on the same page about what the valid market problems are that they will be solving with a new feature or product. If only one person undertakes this activity, or there is too much of a reliance on the market to dictate the real problems, there is a serious risk that the real problem will be overlooked and the wrong solution developed.

To identify market problems, product teams must work together and with their customers and users to understand, analyze and then validate what the real problems are that need solving.

The solution that solves the problem needs to be validated too. 

When you start thinking about how to solve a problem, there is a good chance you will think of more than one way to do it. In fact there is almost always more than one way a problem can be solved.

In product management, there are also factors that influence how a problem can be solved—the budget a company has to develop or enhance a product, the market segment the product is being developed for, the amount of time a company has to develop the product before their competitor does, and even the level of complexity and effort that should be used to solve a problem. Some problems we may need to develop a new generation of product for, other problems we may only need to apply small enhancement and maintenance upgrades to. Both approaches could result in the same level of value and satisfaction for a user.

Collaboratively analyzing problems and coming up with the most effective solution is all part of determining and validating the solution to an identified problem. Problems are solved more effectively when done by a team of people, and solutions are more valuable when they are constantly validated throughout the development lifecycle.

Let’s talk about why collaboration is so important when it comes to defining valuable solutions.

As individuals, we simply don’t have all of the different perspectives, experiences, and knowledge to brainstorm all potential problems and solutions ourselves. Our perspectives are filtered by our past experiences, and we can very quickly fall into the traps of confirmation bias and functional fixedness.

Confirmation bias is a human tendency that happens when we already think we know what the solution or problem is without really examining if we might be wrong. Subconsciously, we do it all the time—we look for evidence to support what we already believe. We seem to remember only the times our favorite sports team has won yet tend to easily forget about all those times they have lost—or maybe we only tend to research the information to confirm our already formed opinions when it comes to write a new article. Or have you ever noticed that when you buy a new product—maybe the newest phone, or a new car, that you start to see it everywhere you go? That’s confirmation bias—it’s us looking for evidence that we purchased the right product. In product management, confirmation bias can present a real threat to both understanding what the real problem is, or determining what the best solution is to build when it is undertaken by only one person, and not questioned by the team. 

We also tend to get trapped in a cycle of what is called functional fixedness—meaning that we tend to approach solving problems in the same way over and over again, especially if we are familiar with the components of it.

Want to test it out and take a break from reading?  Try the following test designed by psychologist Karl Duncker to illustrate the effects of functional fixedness:

Given the following items:

         Collaboration   Collaboration   Collaboration 

How could you fix the candle to the wall so that the candle’s wax does not drip onto the floor below?

 Well if you are like most people, resolving this problem is a challenge. Often, individuals alone cannot approach a problem from different angles to fully explore all viable solutions. In the case of the thumbtacks, matches, and the candle—many people get stuck thinking only of the objects as they are presented, which are in the boxes. But remove the thumbtacks or matches from the boxes and ask them the same question, and they are more likely to get it right:

To fix the candle to the wall so the wax does not drip, remove the thumbtacks from the box, place the candle in the box, and tack the box to the wall so it catches any dripping wax.

Most individuals get stuck on thinking about the problem in only one way—but when they are allowed to collaborate with others to discuss possible solutions, many tend to get the answer eventually right. When we apply functional fixedness to product management, we can immediately start to see why brainstorming solutions needs to be a collaborative effort—it is too easy for a single person to miss a potential solution. 

We also can’t forget about the role customers and users of a target market can play in validating the solutions we come up with—before they ever make it to the market. The product discovery phase of a product’s development is arguably the most important time to engage your customers and end-users in understanding the problem and what the best solution will be. Collaborate with your market by inviting them in for focus groups, calling them up to elaborate on requests or complaints—drill further down into their issues, and ask them to contribute towards or rate the various solutions your team has generated.

Before any product idea moves into development you want to have it validated by the market you are trying to sell it to—doing so will save you time, money, and many frustrations down the road.

Once the solution is validated, the opportunity needs to be as well.

The development of a product needs to be mutually beneficial for all stakeholders involved—the customers, the users, and the company investing in the development of it. The product development team may have thought of a really great feature to solve a real problem with—but that doesn’t always mean it will be beneficial for the company to develop it. Thought and consideration needs to be put into how an identified solution can also help the company achieve its goals. No feature or product should be developed until it is determined it can actually be developed successfully.

To do this, a collaboration and validation process needs to take place with the relevant internal stakeholders to determine that the identified opportunity is one that is worth a company undertaking. The team together needs to answer the questions: ‘how will solving this problem help our business?’, and ‘why us? What makes our company capable of solving this problem successfully?’

Stay tuned for the next blog post that talks about collaboration through the next phase of the product development lifeycle: product delivery.

  See how our software can help you with stakeholder engagement







Migrating Applications to the Cloud: A Guide for PMs and BAs


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


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 do it faster. Aberdeen Group found that businesses that used the cloud were able to resolve issues in an average of 2.1 hours, nearly four times faster than businesses that didn’t use the cloud (8 hours).

Services can Be Paid with OpEx

Cloud computing services are typically pay as you go, so there’s no need for capital expenditures. Because cloud computing is faster to deploy, businesses have minimal project start-up costs and predictable ongoing operating expenses.

Increased collaboration

Cloud computing increases collaboration by allowing all employees – wherever they are – to sync up and work on documents and shared apps simultaneously, and follow colleagues and records to receive critical updates in real time. A survey by Frost & Sullivan found that companies which invested in collaboration technology had a 400% return on investment.  Cloud infrastructures generally have much better capabilities to accommodate global scaling and often have significant latency in Worldwide deployments than internal corporate networks.


Let’s face it, people want access to IT services no matter where they are. For example, someone might be in Peru on vacation and need to process and approve transactions in the United States. Running applications in the cloud enables people to work from anywhere. All employees need is to have Internet access, which is widely available across the world. Many people now from home or work remotely in various places; Cloud computing enables this.


One of the serious concerns about the Cloud is about Security. However this does not seem to be as serious as the hype put out by IT departments. Most corporate IT departments are nowhere near sophisticated or have the resources or experience that Cloud vendors do in this area. In reality, major cloud vendors (IBM, Amazon, Microsoft) are far more sophisticated and have much better understanding and resources of security than corporate IT departments.

Some 800,000 laptops are lost each year in airports alone. This can have some serious monetary implications, but when everything is stored in the cloud, data can still be accessed no matter what happens to an individual laptop.


Implementing a SaaS application is much quicker than implementing traditional software applications. SaaS applications can often be provisioned and available the same day. Users can often start productive work within days not months. There is no hardware to buy, desktop software to deploy, or complex implementation issues. Users can often start training through online video classes and practice using the system in a sandbox.

Organizations seeking to move applications into the Cloud have three primary options:

    • Rehost on infrastructure as a service (IaaS),
    • Rebuild on platform as a service (PaaS), or
    • Replace with software as a service (SaaS)

Let’s explore each of these options:

Rehost – Rehosting involves moving the application and its components residing on internal corporate servers to servers hosted in the Cloud. Rehosting an application without making changes to its architecture can provide a fast cloud migration solution. However, this may not always be the best method. It may be better to also make some architectural changes to take advantage of improved security, scalability, and business continuity when moving applications to the cloud.

Rebuild – Rebuilding the solution means discarding the existing solution and rebuilding the solution using software and tools provided by Platform as a Service. One of the major PaaS vendors is provides a complete environment for quickly building new applications. Using makes a lot of sense when you are using as your CRM and you have additional applications that need to interface with it. It is often easier, faster, and cheaper to rebuild the applications in instead of trying to integrate legacy applications with

Although rebuilding requires development of new skills and loss of knowledge of existing code and frameworks, the advantage of rebuilding an application is access to innovative features in the providers' platform. PaaS can significantly improve developer productivity, allowing teams to deliver solutions faster than they could with the old legacy code that they maintained before.

Replace – Replacing an application involves replacing an existing application (or set of applications) with commercial software delivered as a service. This option avoids investment in mobilizing a development team when requirements for a business function change quickly.

A new tool that can really help with migrating application to the cloud is offered by Enfocus Solutions. First, the tool is a SaaS based offering and ready for immediate use.  Next, it provides many capabilities to help with difficult decisions of migrating applications to the cloud such as:

    • Documenting business processes
    • Documenting problems and opportunities for improvement in processes
    • Documenting legacy applications that support the business processes
    • Documenting and analyzing whether applications should be rehosted, rebuilt, or replaced
    • Defining nonfunctional requirements for IaaS and PaaS
    • Defining functional requirements for SaaS
    • Defining transition requirements for moving to the new application
    • Performing fit/gap analysis of SaaS vendors
    • Measuring Business Outcomes

Overall the tool from Enfocus Solutions provides an excellent method for defining and managing your cloud migration strategy.

Find out more about Enfocus Requirements Suite™.

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


collaborationWe’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 reason products fail is because market needs are not understood and a solution is defined before understanding what the real problem is.

You might recognize a few symptoms that result:

    • You seem to be operating within a ‘reactive’ product development environment—when you’d much rather be operating within a strategic one. 
    • Keeping up with the competition seems like a furious and constant battle.
    • Your company keeps launching new features but your customers don’t seem to be using them all that much.
    • The number of products returned is far higher than expected.
    • A backlog of features is piling up higher and higher with what feels like no real direction on what to do with them.
    • You’ve forgotten what the voice of the customer sounds like within the chaos.

The key to understanding the market problem is to make sure that the right amount of time is being invested in doing so—and that it is being done collaboratively.  When you rely on only one or two people—or even just your market alone—to define what the market problems are, the risk of missing the underlying cause rises significantly. Time needs to be invested in analysis and understanding of the market evidence.

As the complexity of products increase, so does the need for collaboration. 

As consumers ourselves, we’ve all noticed how the complexity of products has increased over the years. The basic cell phones we used to carry around with a screen barely big enough to read a single text message have evolved into smart phones with screens three times the size and more features than we can even name or use (especially when you consider what most of them do to battery life!).

Now, couple that increase in functional complexity with the current level of competition in most markets—and what you’ve got most times are companies constantly rushing to launch new features or products just to try and stay in the game. Problem is, they are starting to forget about what the actual problem is they are trying to solve with all these releases—or if they are even solving one at all. According to the Standish Group’s 2013 Chaos Manifesto report, it’s estimated that only 20% of a product’s features are used often. Yes, only 20%. The rest are hardly ever used (50%) or used infrequently (30%). When you start to translate the time and resources it takes to develop that 80% of features never or infrequently used—well, it certainly makes you stop and think how your company could better be spending their time and money.

One of the largest challenges companies have in today’s market is the constant pressure to release new features and products quickly in order to keep up with the innovation being driven by technological advances. It goes without question that with the constant pressure and increasing functional complexity of products, the processes to develop the products also becomes more complex. More people are involved in the development of the product, teams are spread out in different geographical areas, and there is an exponentially greater risk that the product team will fall out of sync with one another and end up with a product that does not solve any real market problems, or if it does—it’s taken longer than the competitor to release it.

To keep up with the pace of the market and complexity of products, product teams need to work collaboratively now more than ever. Without the synchronicity that collaboration drives, there is simply too much time lost in the product cycle to stay ahead of the competition.

What do you do to make sure your team is in sync with one another? What are some of the problems that you face trying to enable collaboration on your teams?

Next week, we’ll post a second blog in this collaboration series that explores the collaboration conundrum furthers and looks at what the key activities and opportunities are for collaboration during the product discovery and delivery phases of a project. 

Read Part 2: Collaboration - Working together through Product Discovery

See how our software can help you with stakeholder engagement

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.

Business Analysis

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.

Register for free webinar on Requirements: The Old Way and The New Way

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


CMO and ITLately, 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 automation. We are seeing many entrants in this market with solutions offered by Hubspot, Marketo, Salesforce Pardot, Oracle Eloqua, and Act-On. Much of this is driven by the rise in popularity of social media sites, mobile applications and other web-based tools. Marketing departments are now beginning to monetize ongoing consumer conversations using social media monitoring tools provided by companies like Hootsuite,  SDL, SproutSocial, and Radian6. The social media opportunity is huge and even traditional IT companies such as HP have recently joined in. The number of players and the amount of noise in this area is growing rapidly.

Another key trend is the use of big data for marketing purposes. Data analytics and business intelligence allow marketing to sort through the noise of customer data to gather the right information that is needed for product innovation, advertising, and much more. The correct customer data provides marketers with what they need to not only understand customers have done, but to predict what they will do. 

The vast majority of marketing applications are provided as cloud services. Most cloud services can be paid for using OPEX funds, allowing Marketing departments to purchase key applications services and completely bypassing IT investment governance.

Marketing is a major player in the push for Bring Your Own Device (BYOD). Marketers want to use various mobile computing devices; many are designers and are demanding to use Apple computers. If they do not get the support of IT, they simply bypass IT and do it anyway. IT may object, but you can guess who wins when the decision goes to the CEO.  BYOD frustrates IT for many reasons; they do not like losing control of the desktop and the devices attached to the network. However, many IT departments have received mandates and have been tasked with making the enterprise Apple-friendly (and increasingly Android friendly) and to adopt to a number of other devices such as tablets and tv media devices. BYOD in combination with a diminishing IT budget and cheap enterprise hardware and software deals has resulted in an IT department that is lagging and no longer the innovator that they were considered to be in the past. Many IT departments have even been accused of holding their companies back and placing their organization at a competitive disadvantage. Once involved and heavily invested in by the C-suite, the CIO has now taken a back seat to the CMO, as consumers are driving what tech products and services they want at home and in the workplace. CIOs must now accept this trend or look for another job.

Marketing has been traditionally underserved by IT. Because of the lack of marketing domain knowledge in IT, many CMOs have hired their own CTOs to guide their technology strategies. The tension between marketing and IT is actually quite natural given the way most organizations are structured. IT and marketing simply have different incentives and priorities. IT is primarily concerned with stability, security, cost, standardization, and functional specs, whereas marketing is more concerned with speed, agility, innovation, market impact, differentiation, and customer experience. It’s not that IT doesn’t appreciate marketing’s priorities — or vice versa. It’s just that their incentives cause them to value their own respective priorities more.

According to a new study by Accenture Interactive, 60% of CMOs and 73% of CIOs say that technology is essential to marketing in the evolving digital landscape. Furthermore, 77% of CMOs and 56% of CIOs rank each other's departments as part of the top five business units with which they need to collaborate. However, according to the same survey, only one of every ten executives surveyed believe the CMO-CIO relationship and collaboration is at the right level. If you are a project manager or business analyst in IT, encourage your CIO to more closely collaborate with the CMO.  Ask to work on IT marketing projects and you will have a bright future.

Register for free webinar on Requirements: The Old Way and The New Way

Business Analysis and Project Management Trends in 2014


business analysis trends 2014Normally, 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 more on understanding stakeholders and their needs, analyzing business change, and delivering value. The role of business analysis in enabling business change will become more important than defining user stories, which is primarily done by agile product owners and teams.
5. Managing Value not Tasks – According to the Gartner Group, program and portfolio management (PPM) is a growing area of need for many organizations; however, the results it delivers often don't live up to expectations.  According to Gartner, Since 2008, there has been a high rate of Project Management Office (PMO) startup activity with an implementation failure rate of more than 50%.  Organizations must consider moving beyond traditional IT portfolio management to align with mission critical business objectives. The focus of PPM must shift to be able to adapt to changing strategies to create maximum business value for minimum cost, quickly. Gartner is bold to say: “PPM leaders must prepare for extreme transformation or prepare resumés. Enterprise Portfolio Management Offices (EPMOs) are beginning to emerge. The key driver is the need to merge technology and business projects under the same organization. 
6. Measuring Business Outcomes – CEOs are placing more demands on CIOs to show more value from dollars invested in IT.  PMOs will be asked to demonstrate how projects have improved business outcomes and achieved expected ROI. Defining Business KPIs will become a standard skill for business analysts and will become a standard part of defining business requirements.  Business analysts will work with other BAs skilled in BI and analytics to report results using the KPIs defined in the project.
7. Business Analysis and Design Merge – Business analysis and design will merge and become one.  This change is being reflected in name changes to BABOK knowledge areas from Version 2 to Version 3.

BABOK V3 Q1 2014

8. More Emphasis on User Adoption – User adoption is essential to delivering value on projects.  If users do not adopt the solution, then the solution delivers no value. BAs will need to develop user centered design (UCD) and organizational change management skills to be more effective in this area.  This area will become a key part of agile discovery practices.

9. PMs Place More Emphasis on Solution Scope and Requirements – Project managers have begun to realize that requirements and managing solution scope are two of the major reasons for failed and challenged projects. The Project Management Institute (PMI) has definitely shown more interest in this area by creating a Requirements Community of Practice, which encourages project managers to become involved in requirement activities. It will not be surprising if Requirements Management becomes the 11th knowledge area in the PMBOK or if PMI offers a Requirements Management Certification, directly competing with the International Institute of Business Analysis (IIBA) and its Certified Business Analysis Professional (CBAP) certification.

10. BAs Help in Choosing Cloud Solutions – More and more infrastructure and applications will be migrated to the Cloud.  Business analysis will play a major role in helping the business define requirements and chose the best option for moving in this direction. Security concerns will be minimized as commercial Cloud vendors have far outpaced corporations in the security area.

Register for free webinar on Requirements: The Old Way and The New Way

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. 

unwanted product featuresAs 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 companies, customer visits, interviews, and the list goes on. Other companies just start firing off every requested feature to development in a constant battle against the fire of the market. And still other companies don’t even approach the market and make the decisions for them what they want. Sometimes these methods work, but many times, as evidenced by the Standish report, they do not. And all of them can be very expensive.

The key to this company’s success I was reading about? Nothing fancy really - they simply read through product reviews on Amazon, and then filled in the identified gaps with products that meet what the market is looking for. And that’s it —they have a team dedicated to browsing the comments and looking for comments such as ‘This product was okay but I wish it had…”, or “This is almost what I need, but I also need it to do…”. Then they just fill the gap by producing that product—they have literally become a million dollar company just by doing this one simple market sensing activity.

Which I find interesting for a few reasons: 1) because it seems so logical, 2) because it seems while it can take time and effort to do, it would be a relatively straightforward and accurate means of market sensing, and 3) because it removes the direct interaction between company and consumer and simply uses the market’s naturally occurring conversations to derive what they want.  The company was no longer leading the conversation via a focus group, or an interview, or a survey—but they were going where the conversations around what the market wants occur in a very natural way.

And that last point is what I find most interesting. 

It also reminded me of a webinar I attended a couple years ago by Keith Goffin (author of “Identifying Customers Hidden Needs”) that talked about this very concept—that even when we ask the market what the need is, we cannot really get accurate answers. And that what the market really wants, is often hiding beneath the surface, in their subconscious.

To see what I mean, I am going to run through a method covered in the webinar called the ‘repertory grid’ technique.

So, pretend you are my target market and I am looking for ways to improve the phone you currently have—I ask you to name any six features of that phone, and then put them into numbered cards as such:

prioritizing features

And then maybe I ask you the question:

“How does feature #5 (voice command) differ from features #2 and #1?”

And you may reply something such as: “It’s easier to access than the others,” or, “It’s more fun to use than the others.” Or if you really hate one of the features you may reply something like “at least it works.”

And then I would continue on to ask you a series of similar questions all comparing and contrasting the features. And from your responses I would come up with a list of constructs to compare the other features against. 

So for example, constructs from the above examples might be:

  • “Easy to access”
  • “Fun to use”
  • “Makes me more productive”

The constructs are all the natural ways that you have come up with describing these features. 

I would then take those constructs and ask you to rate them for each feature in a grid, which may look something like this:

customer prioritize features

And ask you to rate each one on a scale of 1 to 5 – so for example: “On a scale of 1 to 5, with 1 being really easy to access and 5 being incredibly frustrating, how would you rate the Email feature? How would you rate the Maps feature?” and so on. 

In the end, you may have a grid similar to this:

customer needs prioritization

Then, as the product manager or person responsible for discovering how a product can be improved, you can start to pull out all the highly rated scores against the features and look for improvements. 

In the above case, there are quite a few 4’s and 5’s, meaning there is probably a lot of room for improvement.

So what is the biggest difference between finding out what a customer needs this way versus just asking them what features they want in a phone or how it can be improved? Well, the biggest difference is the entire conversation is driven for the most part, by the customers themselves, using their own words and without any leading. Many times when we do direct interviews, or focus groups, we are asking specific questions in a specific way—and it can limit how a customer expresses what they need in a product. When we give customers the ability to naturally express their thoughts on a product, what we get as a result is much more valuable input as to what they are looking for, and they often come up with constructs or descriptions that we as a company never would have thought to use were we coming up with questions for an interview or focus group.

There is value in letting the customer drive the conversation—whether it be through the repertory grid approach outlined above, or by going to a place where the conversation naturally occurs itself, such as Amazon product reviews. More times than not, this approach can give companies a much better shot at really developing features the market wants, features they need, and ultimately features they will use.   

Involved in product development?Find out how Enfocus Requirements Suitewill make your life easier!

Rescuing a Troubled Project


According to the Standish Group, over 60% of projects fail or are challenged.

Screen Shot 2014 02 28 at 1.53.03 PM

Gartner Group 2011 research shows the same story; only it paints a slightly worse picture.

project success rates gartner

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.


  • 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 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 it appears unlikely that the project is able to deliver the anticipated business value, then the project should be canceled instead of recovered.

 The following project turnaround model presents a good method for getting the project back on track:

  • Assess the Troubled Project
  • Develop a Recovery Plan
  • Execute the Recovery Plan
  • Monitor and Measure the Recovery

Managing Solution Scope

A vast majority of projects run into trouble because solution scope is not well defined or managed. There are two types of scope on a project: project scope and solution scope. Project scope involves defining the work that will be performed. Solution scope defines the features and functions that will be included in the solution. Project managers are generally very good at defining project scope but generally not very good at defining solution scope as this is a business analysis responsibility and not part of the project management domain. However in most organizations, business analysis maturity is so low that BAs start with defining solution requirements and are not even aware of what solution scope is.

Defining solution scope is perhaps the most important part of the upfront process of planning a project. However, it is seldom done well. If you don't know for sure what you are delivering and what the boundaries of the project are, you have virtually no chance of success. Managing solution scope is one of the most critical aspects of managing a project. However, if you have not done a good job of defining scope, managing scope will be almost impossible. Failure to define solution scope well almost always results in scope creep, as well as budget and schedule overruns.

In the most recent CHAOS Manifesto, Standish Group analysts strongly recommended two key practices concerning solution scope:

  1. Break the project into small independent Components or Features that can be delivered independently.
  2. Focus on high value features and eliminate features that provide little or no value.

The Standish Group flatly states that that “there is no need for large projects, and that any IT project can be broken into a series of small projects.”  It is important not to interpret breaking down projects into smaller projects as defining milestones, phases, critical paths, and activities. Delivery of concrete and usable results demarks a successful completed project. Small projects deliver a valuable result that is actually used to create a return on investment (ROI).  The benefits of using this approach are quickly evident when the organization starts to receive value early in the project cycle. The probability of success is 10 to 20 times that of running a single large project.

Standish Group Research shows that 20% of features are used regularly and 50% of features are hardly ever or never used. The gray area is about 30%, where features and functions get used sometimes or infrequently. Focusing on the 20% of the features that give you 80% of the value will maximize the investment in software development and improve overall user satisfaction. Reducing scope and not delivering 100% of the functionality is not only a valid strategy, but a prudent one.

The first step in recovering a falling project is to focus on the solution scope.  If it has not been defined well, then this is the place to start in the project rescue.  Organizations that place more focus on solution scope in the first place will have less need to rescue failed projects. If your organization is struggling in this area, please request a consultation from Enfocus Solutions. We offer consulting services and technology to help you in this vital area for successful projects.

Register for a product demo webinar to see how we can help rescue your projects

Requirements Management Tools versus Robust Business Analysis Tools


babok knowledge areasIn one of my recent blog articles, Risk Management: Business Analysis is a Huge Risk for Most Organizations, I stated that business analysis is at a dangerously low level of maturity for most organizations as evidenced by Standish Group Research, which analyzes project performance.  Standish Group Research shows that the top five reasons for failed or challenged projects are:

  1. Lack of user involvement
  2. Lack of transparency
  3. Poor or incomplete requirements
  4. Changing requirements
  5. Lack of business alignment

Now, examine these problems carefully; all of them are related to poor business analysis.  Looking at this and other research, I firmly believe that poor business analysis is the number one cause of failed and challenged projects. According to the Business Analysis Body of Knowledge (BABOK), business analysis involves much more than just writing solution requirements. However, in many organizations, BAs only write solution requirements and do not perform other key activities specified in BABOK. For example, few business analysts are actually involved in Enterprise Analysis and Solution Assessment and Validation which are two key knowledge areas specified in the BABOK.

Many people think that Requirements Analysis and business analysis are one in the same. Requirements Analysis is only one of the six knowledge areas in BABOK. It’s important to stress that there is much more to business analysis than just writing solution requirements.

Many confuse requirements engineering and business analysis, thinking they are one in the same; however, they are not. Understanding the differences is key for successful IT projects. Requirements engineering, although helpful, is certainly not the key for success on business IT projects. Requirements engineering might address problems 3 and 4 of the Standish Group problem list, but would do little for 1, 2 and 5. Let’s explore the differences between the two.

Requirements Engineering (RE)

Requirements engineering is a systems and software engineering process which covers all of the activities involved in discovering, documenting, and maintaining a set of requirements for a computer-based system. The first use of the term 'requirements engineering' was probably in 1979 in a TRW technical report, but the term did not come into general use until the 1990s with the publication of an IEEE Computer Society tutorial and establishment of a conference series on requirements engineering.  Requirements engineering is often very rigid and engineering-focused as it originated from the IEEE world.  The focus is clearly on developing engineering specifications for a product and not delivering business value in an environment that must address people, process, and technology. With the rapid adoption of agile development practices, some industry observers have questioned if requirements engineering is still relevant as it is a process for software engineering, which agile has mostly replaced.

Requirements engineering is primarily focused on building products and does not include many of the other activities involved in business analysis such as business process improvements, building a business case, or delivering business benefits. Basic traits for requirements engineering include:

  • Solutions are engineering-driven and focused on delivery of product features, not business benefits.
  • Requirement engineering typically deals with large complex systems in which software is only a component (e.g., airplanes, naval vessels, hydroelectric plants, etc.).
  • Two primary requirements engineering activities:
  • Requirements development.
  • Requirements management.
  • Requirements are related to products, not processes.
  • Requirements engineering addresses only Functional and Non-Functional requirements while ignoring Business, Stakeholder, and Transition Requirements.
  • Requirements engineering does not work well for agile development practices where lighter requirement practices are used (user stories) and focus is placed on collaboration and less on rigid engineering practices.

Business Analysis (BA)

Business analysis is much broader than requirements engineering. The focus of business analysis is to deliver solutions that improve business outcomes. Software is usually one part of the solution. Business analysis also addresses people and process issues in addition to technology. Below is a list of BA characteristics:

  • Solutions are business driven and aligned with business needs.
  • Business analysis is used for enterprise projects where people, process, and technology issues must be addressed.
  • Four primary requirement activities:
  1. Elicitation.
  2. Requirements development.
  3. Requirements management.
  4. Requirements communication.
  • Solutions are focused on using technology to help people performing business processes.
  • Solutions are often purchased instead of built (ERP Systems, Cloud Applications).
  • Addressing organizational change and business process change is critical for successful business analysis.
  • Business analysis involves facilitating business change.
  • Delivering business value and ROI are expected.
  • There are five types of requirements: Business, Stakeholder, Functional, Non-Functional, and Transition.

Selecting a Business Analysis Tool

I have worked with many organizations that simply do not understand the difference between a business analysis tool and a requirements management tool. The vast majority of requirements management tools on the market support requirements engineering and provide little or no support for business analysis. A requirements management tool can work very well for defining and managing requirements for a product.  However, the product that is built may not deliver any business value or may not help users perform their activities because the requirements tool used only allows for defining Functional and Non-Functional Requirements and does not allow for capturing business and stakeholder requirements. If your goal is to deliver business outcomes and help users better perform their daily activities, then chose a business analysis tool and not a requirements management tool. 

At present, Enfocus Requirement Suite™ is the only true business analysis tool on the market. If you are in a Corporate IT department and you are selecting a tool for product requirements, you are probably selecting the wrong tool. IT departments deliver services and do not usually develop products. If you are looking at tools and see taglines such as the ones below, be careful to ensure that you are choosing the right tool for your needs.

  • Requirements Definition and Management Software
  • A Better Way to Manage Requirements and Deliver the Right Products
  • Software for Managing Requirements
  • A Tool for Managing Product Requirements

A business analysis tool includes many capabilities beyond just requirements.  Below are distinguishing characteristics of business analysis tools:

  • Addresses all knowledge areas in IIBA’s BABOK:
  1. Business Analysis Planning and Monitoring
  2. Elicitation
  3. Requirements Analysis
  4. Requirements Management and Communication
  5. Enterprise Analysis
  6. Solution Assessment and Validation
  • Captures all five types of requirements as defined by the IIBA (Business, Stakeholder, Functional, Non-functional, and Transition).
  • Focuses more on customer collaboration over rigid engineering specifications.
  • Can define the business case within the tool.
  • Addresses people, processes, and technology, not just technical specifications.
  • Can trace requirements to needed business processes changes, IT services and organizational change initiatives.
  • Provides a stakeholder impact assessment capability within the tool.
  • Captures stakeholder needs separate from requirements with full traceability from requirements to stakeholder needs.
  • Can define the problem statement within the tool.
  • Can trace requirements to specific business objectives.
  • Can record expected business outcomes in the form of measures or KPIs.
  • Focuses on collaboration between stakeholders and developers, placing more emphasis on collaboration and less on rigid requirement documents.
  • Allows stakeholders to be engaged throughout the project lifecycle, not just upfront in requirements definition.
  • Allows the requirements to be used for benefits realization after the solution has been delivered.
Register for free webinar on Business Analysis is a Process, Not a Role

Guidelines for Dual-Track Agile Project Management


agile project managementIn our previous blog on Dual-Track Agile, John Parker described the benefits of this emerging concept. Dual-track agile is an approach to agile development in which project teams are constantly working on the discovery and delivery of solutions that will deliver business value and obtain user adoption. By following the principles of dual-track agile, project managers and their teams can eliminate a lot of frustration and costs in agile development. Below are the key guidelines to implementing dual-track agile in your projects.

1. Put together a proficient discovery team with expert capabilities who are able to blend entrepreneurial skills and research gathered from the market. Your team needs to have the following skills so they can thoroughly and effectively understand the problem, recommend the best solution, and align the project with business needs:

  • User Experience/User-Centered Design
  • Business Analysis
  • Pricing and Financial Analysis
  • Customer Discovery
  • Impact/Gap Analysis
  • Focus on Collaboration
  • Experimentation Attitude

2. Have the discovery team working one or more months ahead of the development team. The discovery team should be constantly populating the backlog with validated ideas and user stories. 

3. With the help of the discovery team, create an understanding of your customers’ core problem before gathering ideas/features. Do not start putting together a solution until you have a complete understanding of the problem. Use Root Cause Analysis techniques like Fishbone Diagrams or The Five Whys to dig deep into the source of the problem and set the context for the project.

4. Develop a shared vision by hosting a vision planning workshop. Invite the product owner, business stakeholders, technical subject matter experts (SMEs), user-centered designers, and customer representatives. Before the end of the meeting, ensure everyone understands the problem or opportunity and why it is important.

5. Develop a clear set of business objectives for the project to ensure the delivered solution achieves critical business outcomes laid out in the vision. Once ideas or features are documented, business objectives will be referred to for validation. All features must align with business objectives.

6. Do not allow user stories to be defined until ideas/features are fully documented and validated.

7. With the guidance of user-centered design specialists, validate ideas/features to ensure they meet business needs and eliminate low-value features. With the help of business stakeholders, customer representatives, and technical SMEs, validate that each feature is:

  • Accurate
  • Complete
  • Clear
  • Prioritized Correctly
  • Feasible
  • Testable

8. For every validated feature, develop a complete set of user stories. Make sure your user stories consist of  the Three C’s:

  1. Card
  2. Conversations
  3. Confirmations

9. Each user story needs to be written in a consistent format and follow the INVEST model: 

  • Independent
  • Negotiable
  • Valuable
  • Estimable
  • Sized Right or Small
  • Testable

10. It’s important for the discovery team to collaborate with each other and provide support to the development team. Use collaboration mechanisms such as feedback elicitation, stand-up meetings, demonstrations, and retrospectives. Discovery teams should have frequent interaction with developers, business stakeholders, and the QA team.

If you’re a PM needing help on implementing these guidelines, Enfocus Solutions Inc. provides a complete solution for dual-track agile development by helping teams focus on discovery to ensure projects deliver value to the business, customers, and users. Download the white paper below or contact us for a consultation to find out how we provide a complete solution for powering business value, reducing waste, and increasing ROI on projects. 

Download our white paper onDual\u002DTrack Agile for Project Managers

All Posts