by John Parker | Feb 21, 2014 | Agile, Business Analysis, Project Management, Uncategorized |
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...
by John Parker | Feb 6, 2014 | Business Analysis, Uncategorized |
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...
by John Parker | Feb 3, 2014 | Business Analysis, Uncategorized |
By proactively identifying and eliminating or remedying poorly performing application assets, Application Portfolio Rationalization helps companies to: Reduce costs, Target efforts to the areas of highest return, and Maximize the business value of their application portfolios. Globalization and changing business requirements impose significant challenges on technology leaders who are under constant pressure to both innovate and reduce costs. These demands to do more with less have been exacerbated by business leaders hearing about prospective savings from use of the Cloud without understanding the impact of transition. Many organizations are electing to combine their initiatives for application rationalization and migration to the cloud. IT leaders are forced to accelerate the rollout of new systems and technologies to support the business without compromising the performance of existing applications. They must address key issues, such as balancing cost, complexity, and capacity, and also deliver business value by applying continuous improvement methodologies. Application portfolio rationalization helps organizations turn these challenges into benefits in terms of reduced costs and more value delivered to the business. Application portfolio rationalization is an important and continuous exercise for evaluating and controlling IT costs. Application portfolio rationalization involves focusing on the application portfolio looking for redundant applications, one-off technologies, applications with few users, and applications with a high cost/user ratio. With a complete understanding of the current environment, the next step is to consider what should be done to move from current to the ideal. Gartner Group research confirms that a focused application rationalization effort will typically result in substantial cost savings while improving support for the lines of business. These savings are too large to ignore. Additional...
by John Parker | Jan 31, 2014 | Business Analysis, Uncategorized |
Ask someone about business value and you will most likely get a blank stare or many different answers. Is business value the same thing as Shareholder Value or Customer Value? OK—if all else fails, let’s go to Wikipedia; it is always a trusted source right? Here is the definition of Value in Wikipedia: In management, business value is an informal term that includes all forms of value that determine the health and well-being of the firm in the long run. Business value expands concept of value of the firm beyond economic value (also known as economic profit, economic value added and shareholder value) to include other forms of value such as employee value, customer value, supplier value, channel partner value, alliance partner value, managerial value, and societal value. Wow, I don’t think this helps much. Let’s look at another source. IIBA’s new BABOK (Version 3) that will be published this year is heavily focused on value. IIBA recently conducted a webinar on Value and posted it on YouTube. According to the IIBA and the new BABOK, value is defined as “The importance of something to a Stakeholder in a Context.” I am not sure that I agree with IIBA’s definition of value but I definitely agree with the IIBA when they say “Value is not understood.” At first look, this definition is nebulous, but it has components that are very important. There are three key words here that we have to focus on: Importance, Stakeholder, and Context. Importance – Importance allows us to compare one option to another and make decisions in terms of what delivers the most value....
by John Parker | Jan 29, 2014 | Business Analysis, Uncategorized |
The Standish Group 2013 CHAOS Manifesto Report titled “Think Big Act Small” presents two core concepts to achieve more successful projects. The first key is to break a project down into small independent components that can be managed and delivered separately. The second key is eliminating features that provide little or no business value. Let’s examine both of these. Breaking a Project Down It is important not to confuse breaking down projects as simply defining milestones, phases, critical paths, and activities. These are simply components of a single large project. It literally means breaking a project down into a series of independent smaller projects. Each smaller project is defined, developed, and delivered independently producing a valuable result. The Standish Group says “A large project has virtually no chance of coming in on time, on budget, and within scope, which is The Standish Group definition of a successful project.” The Standish Group reports that large projects are 10 times more likely to fail, meaning the project will be canceled or will not be used because it outlived its useful life prior to implementation. In contrast, small projects have more than a 70% chance of success. Breaking down a large project into a series of smaller projects does not require migrating to agile, although use of the agile methodology can help in this regard. Breaking one large project into five or ten smaller projects and delivering each one independently can greatly improve the likelihood of overall success. Breaking down a project is not always easy, but can be done. The writers of this CHAOS Manifesto Report state flatly that they have come...
