by John Parker | Aug 8, 2012 | Business Analysis, Uncategorized |
BABOK V2 describes Transition Requirements as “capabilities that the solution must have in order to facilitate transition from the current state of the enterprise to a desired future state, but that will not be needed once that transition is complete. They are differentiated from other requirements types because they are always temporary in nature and because they cannot be developed until both an existing and new solution are defined.” In simpler terms, transition requirements are what needs to be done to transition to the solution. Below is a list of various types of transition requirements. Data Conversion and Migration Data conversions Temporary interfaces User Access and Security Rights Security privileges User access User Acceptance Testing Test case development Test facility Production Turnover and Transition User support and help desk Operations Application support User Preparation and Transition Skill enhancements Training delivery One-on-one support Super user programs Customer and Supplier Preparation and Transition Communications and notifications Data interchange Pilot Testing Model office Pilot test Organizational Changes Temporary staffing for backfill New hires Transfers Outplacements Infrastructure Transition Servers Storage Network Personal computing devices Changes to Policies, Procedures and Forms Policies Procedures Workflow Forms Business Continuity BC contracts DR Testing No matter how good the code, with out attention to transition requirements, stakeholder won’t be satisfied with the result. [cta...
by John Parker | Aug 1, 2012 | Business Analysis, Uncategorized |
Demand for good business analysis skills is high, and for good reason. An investment made in improving business analysis capabilities can have huge payback. Simply stated, organizations that have not developed strong business analysis capability are at a competitive disadvantage. Enterprises with strong business analysis capabilities have achieved many benefits, including: Implemented solutions that meet business needs Increased the ability of the business to adapt quickly to changes Reduced risk, complexity, redundancy Aligned business and IT Enabled re-use and faster time-to-market Presented one face to the business (customer) Increased business value Conversely, studies routinely conclude that poor business analysis is the root cause of many project failures, resulting in, among other things: Incomplete requirements capture and definition Poor strategic alignment leading to an inaccurate business case Solution design that does not deliver requested features and functions Applications that are not what the business needs The International Institute of Business Analysts (IIBA) describes business analysis as “the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and recommend solutions that enable the organization to achieve its goals.” IIBA describes business analysis as a discipline, rather than as the responsibilities of a person with the job title of business analyst. According to IIBA, business analysis may be performed by people with various job titles such as systems analyst, process analyst, project manager, product manager, developer, QA analyst, business architect, or consultant, among others. In this article, I may refer to a business analyst but I am actually referring to the discipline of business analysis. Anyone...
by John Parker | Jul 23, 2012 | Business Analysis, Uncategorized |
This is the tenth article in a series of blogs discussing individually each of the 12 Keys For Successful Enterprise Projects, published in my blog of Tuesday, June 26, 2012. For all significant project failures, requirements were wholly or partly missing. Whenever a project team jumps directly into implementation (in the mistaken belief it saves time and effort because members “know” what is need) it invariably leads to a delayed or cancelled result. “Build-first-ask-questions-later” projects significantly overrun their budgets and deliver less than optimum systems. Project and program managers, team leaders, and business analysts can use requirements to deliver value on enterprise projects. Specifically Requirements can be used as input to manage each phase of the development lifecycle. This concept is best exemplified in the book by James and Suzanne Robertson entitled Requirements-Led Project Management. Requirements can be used for: Used as input to project planning and decision-making Determine whether to invest in a project Deliver more appropriate products with a quick cycle time Measure and estimate the development effort Drive user acceptance and system testing Manage stakeholder involvement and expectations Establish priorities Communicate across business and technological boundaries Enfocus Requirements Suite™ is designed and fully embraces the 12 principles discussed in this article. Enfocus Requirement Suite™ enables solution teams and stakeholders to work together to deliver successful enterprise...
by John Parker | Jul 20, 2012 | Business Analysis, Uncategorized |
This is the ninth article in a series of blogs discussing individually each of the 12 Keys For Successful Enterprise Projects, published in my blog of Tuesday, June 26, 2012. Maintaining focus on project priorities can be extremely challenging within the culture of large enterprises. According to one industry study, 53% of project prioritization is driven by internal politics. In this climate, adapting more open and transparent project prioritization activities can be extremely difficult. There are powerful people who like the way things are and may have “pet projects” that are near and dear. But that doesn’t mean we shouldn’t try and prioritize by value – it just means bringing change may be harder than we think. One characteristic of excellent requirements is that they are explicitly prioritized. When customer expectations are high, timelines are short, and resources are limited, it is essential to make sure the product contains the most essential functions. Establishing each chunk of functionality’s relative importance lets you sequence construction to provide the greatest product value at the lowest cost. Customers and developers must collaborate on requirements prioritization. Developers do not always know which requirements are most important to the customers, and customers cannot judge the cost and technical difficulty associated with specific requirements. Thus, collaboration and effective communication are key. A project manager has to balance project scope against the constraints of schedule, budget, staff resources, and quality. One balancing strategy is to drop or defer low priority requirements to a later release when you accept new, higher priority requirements or other project conditions change. If customers don’t differentiate their requirements by importance and...
by John Parker | Jul 19, 2012 | Business Analysis, Uncategorized |
This is the eighth article in a series of blogs discussing individually each of the 12 Keys For Successful Enterprise Projects, published in my blog of Tuesday, June 26, 2012. User-centered design, often referred to as UCD, is a design philosophy in which extensive attention is focused on considering the needs, wants and limitations of end users at each stage of the design process. User-centered design can be characterized as a multi-stage problem solving process that not only requires designers to analyze and foresee how users are likely to employ an interface, but to test the validity of their assumptions with regards to user behavior in real world tests with actual users. User participation enhances system quality through a more accurate and complete identification of user needs and expertise about the organization, while concurrently contributing to management of user expectations. Industry research clearly shows that the majority of failed projects can be attributed to incomplete or inaccurate requirements. The biggest cost benefit that UCD provides is defining more accurate requirements that directly address user needs. Design changes made late in the design process typically cost up to ten times more than if it the change were identified during requirements. Making changes to working systems after they are in place will cost about one hundred times more than changes identified in the requirement stage. Ideally, UCD activities should be integrated with other development activities. They should be planned and managed by the development team. Over time, UCD activities will become common practice, and existing members of the team will be able to carry them out. However, usability skills will most...
