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

Q&A on KPIs for Agile Project Managers and Business Analysts

The questions below came from our latest webinar on KPIs for Agile Project Managers and Business Analysts. What are some leading BA KPIs? Stakeholder satisfaction by Feature (Satisfaction) Stakeholder activity by Feature (Engagement) Cycle time from ideation to Feature approval Business value per Feature (Value) Test coverage for Feature (Quality) Number of defects per Feature (Quality) Feature Completeness (Inspection or Peer Review) Is it common practice to have stakeholders sign off on KPIs prior to development? Yes, however, stakeholders should also be actively involved in their development. Getting stakeholder approval is key for all KPIs. What is a good way to minimize the time to get signoff on requirements WITHOUT getting poor/missing/misunderstood requirements? Optimally, requirements should be reviewed as they are being created.  To do this requires an automated requirements tool such as Enfocus Requirements Suite™. Here are some specific recommendations: Break down the solution scope into separate independent components (Features). Validate each Feature and eliminate Features that provide little or no value. Define solution requirements only for validated features. Assign a BA and a Sponsor to each Feature Allow stakeholders to review and comment on each requirement as they are being developed using an automated tool such as Enfocus Requirements Suite.™ Obtain review and signoff on a Feature by Feature basis using stakeholders that are involved in that feature.  This procedure can prevent a lot of noise. Measure the cycle time from Ideation to validation and validation to acceptance. Where can I get the benchmark for any metric? There are many benchmarking services, including: APQC The Hackett Group InfoTech Enfocus Requirements Suite™ (RequirementCoach™) Process Intelligence What tool was...

Software Risk Management

Many project risk managers view risk management as the identification and mitigation of potential events that could affect the likelihood of a project’s success. This view is flawed, as the greatest risk to a project success is not some event that might occur, but rather simply having poor processes and practices for collaboration, project management, discovery, development, or delivery. At the beginning of an initiative, there are many risks associated with getting the requirements right, obtaining active user involvement and adoption, and enabling business change to achieve successful business outcomes.  However, most risk management practices are focused internally on project resources, project activities, and project deliverables.  Risk management practices must change from the current process of focusing internally within the project to an external focus on the business and the users. There are two aspects to software risk: Context and Process. Both of these areas are explained below. Context Risk Understanding the context for risk is critically important. In understanding risk, it is important to gain an understanding of both the organizational and strategic context. Gaining this understanding requires a thorough review of the environment in which an organization exists and operates. It is important to take into account your organization’s specific objectives and capabilities, as well as external factors, such as the changing legal environment and shifting social standards. Establishing context provides the framework for the risk management process. Context risks can be defined in three broad categories: Project, Business Change, and User Adoption, which are explored in the following paragraphs. Project Project context is where risk management has traditionally concentrated. It is generally focused on the work...

The Geek Gap — 7 Ways to Bridge it to Drive Better Business Value

The “Geek Gap” between managers, known as “suits,” and technicians or engineers, known as “geeks,” was growing apparent in 2006 when authors Bill Pfleging and Minda Zetlin wrote The Geek Gap: Why Business and Technology Professionals Don’t Understand Each Other and Why They Need Each Other to Survive. The authors found that the faulty communication caused by the Geek Gap was costing businesses billions of dollars each year in failed IT projects. They reported that in 2003, the Geek Gap resulted in the loss of $55 billion in the U.S. alone, and they predicted that as business became more technology based, the Geek Gap would continue to grow. Now, fast forward a decade, this prediction has held true, and businesses continue to look for ways to bridge the gap between executives and technicians. In their book, Pfleging and Zetl explain that the conflicts arise from the very different viewpoints, agendas, and ideas of how accomplishments are measured. They say suits have numerous pet peeves against geeks. They believe geeks: Don’t understand – or want to understand – anything about the businesses they work in Love technology for its own sake, not considering what new gadgetry might cost Expect that suits understand as much as they do about technology Can never seem to meet deadlines or stay within budgets Think rules shouldn’t apply to them Are bad with people Adding to this, there are several pet peeves geeks have about suits. They believe suits: Refuse to learn anything about technology Don’t understand technology but insist on making technological pronouncements Don’t value technology Only care about money Resist innovation Value image...

Going Green Starts with Effective Business Analysis

Today, businesses are responding to increasing demands to be “green” – to have sound environmental policies and to be transparent about the environmental impact of their products and practices. Beyond the common-sense measures like replacing old bulbs or weatherproofing, going green involves taking responsibility at every stage of a product lifecycle. This calls for in-depth business analysis and an audit of all business processes. In The Green Business Guide, Glenn Bachman describes what it takes for businesses to implement eco-friendly policies, programs, and practices, including how to set up an energy management plan and how to reduce, reuse, and recycle throughout the enterprise. Bachman describes how green organizations recognize the risk of climate change and the degrading of the environment, so they are able to respond with sound business practices. Further, green organizations know how much energy and resources they use and take responsibility for their products. According to Bachman there are many steps involved in planning a green transition, including among others: Define what being a green organization means and outline intentions in going green. Decide who will participate in the plan and identify relevant stakeholders. Set a timeframe for planning and implementing changes. Determine how the organization will measure progress and what tools will be needed. Discuss how implementing a green program will affect other initiatives. Identify potential risks, for instance those involved with using volatile raw materials. Analyze the cost versus the benefits of an environmental program. Make recommendations about which areas to upgrade and what parts of the transition to pursue in each stage. All of these steps call into play rigorous business analysis, which...