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

Requirement Documents, Oh the Inefficiencies!

I’ve written a fair number of requirement documents in my business analyst lifetime, and I’m still not sure what took longer – gathering and documenting the requirements, or trying to get the business to read and approve them. Let me know if this sounds familiar… You spend weeks, maybe months, eliciting requirements, reviewing requirements, and documenting requirements in a nicely formatted word document with the title Business Requirements Document (or something similar) slapped on the front. You are proud of the work you have done, the diagrams you have drawn, the requirements you have logically ordered and laid out for your stakeholders to read – and you’re sure that you have made it down right simple for anybody to just open it up and review it. You happily click send on the email, sure that your stakeholders will read it and send back their input within the requested time frame—after all, who wants to risk the project deadline, right? Problem is, usually stakeholders don’t have the time, or the space, to review a long—and let’s be honest—often boring, requirements document.  Your priority as the BA to get the requirements document reviewed and approved is unfortunately often not their priority—and it’s extremely hard to make it so. Or even when you do get their input, what you receive is often not as meaningful as you were hoping—I remember on more than one occasion receiving a requirements document back with fewer comments about the requirements themselves than about the spelling or grammar style I chose to write it in. In today’s projects, where the dynamics of the solution is constantly shifting,...

Three Golden Rules of Requirements Repositories

Requirements repositories are a method of storing requirements, encompassing those under development, in review, and approved. They are an efficient means of gathering, managing, and leveraging data across the enterprise – including business, stakeholder, solution, transition, project, and quality requirements – along with supporting documentation, such as whiteboard sketches, word processing documents, diagrams, and visual models. Capturing all that information in itself can be difficult. Capturing the information in a repository that is accessible, meaningful, searchable, and sharable presents further challenges. Keeping in mind these three best practices for knowledge management can help. Usability Repositories are only valuable if they’re used. To promote use, the repository has to be part of the daily life of the work environment. It has to function with the overall enterprise architecture, and integrate with other technologies in use, such as Outlook, project management systems, and SharePoint. Also, people have to be able and willing to access it regularly. They have to be motivated to populate a repository. On the receiving end, it has to be easier for them to access the repository for information than to walk across the hall and ask for it. Use of the repository has to be bought into, encouraged, and mandated from the top down and the bottom up. Context The repository also has to be relevant. Requirements are valuable only when they are connected and in context. Imagine the Internet without Google: It’s just a massive amount of information with no context around it. Repositories must provide an easy way for people to search and access the information that has meaning to them. Many businesses seek to...

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

How Business Analysis Can Help Customer Facing Organizations in the Pre-Sales Phase

Written by Kelly Burroughs, Business Analyst – Enfocus Solutions Can you relate to this scenario? You’re a business analyst working in a software company who has been in talks with a potential client for weeks now. The sales team has done a great job showcasing the software, the client likes what they see so far and they’ve requested a statement of work to see what it will cost them. Given the problems your company has run into previously with misalignment between estimated scope and cost of work and actual scope and cost of work, they’ve decided to bring you in to perform a deeper level of business analysis during the pre-sales phase. Your goal? To better understand the needs and expectations of the potential client to help your company deliver a more thorough statement of work, and a more accurate estimate of costs. Win the deal but understand their needs wrong? Chances are your client will feel deceived and won’t be happy about being asked for more money – while your company will take a hit to their reputation as well as their bottom line. But win the deal and understand their needs correctly? Chances are your client will be satisfied – and your company will only build a stronger reputation and bottom line. Fact is, understanding the scope of work that will need to be completed for your potential clients is key to delivering a successful project once you do get the contract. There are few things more frustrating for a client then to sign a contract for an estimated cost, only to be asked for more money...