by John Parker | Nov 27, 2012 | Business Analysis, ITIL and Service Design, Project Management, Uncategorized |
For at least the last three decades, members of the C-Suite have been complaining about the frequency with which IT projects are challenged, under deliver promised value, or outright fail, and with good reason. The most recent Standish Chaos report shows that only 32% of projects are successful, 44% of projects are challenged, and 24% fail. The Standish Group defines project success as a project that delivers planned functionality on time, on budget, and includes all planned features. For Waterfall projects, the percentage of challenged projects is actually higher than it was 15 years ago. These low success rates are surprising given the focus over the last 15 years on project management and the push for project management certification. Agile has helped significantly with project success rates as seen in the table below. According to the 2011 CHAOS report, Agile projects are successful three times more frequently than waterfall projects.The report goes so far as to say, “The Agile process is the universal remedy for software development project failure. Software applications developed through the Agile process have three times the success rate of the traditional Waterfall method, and a much lower percentage of time and cost overruns.” Even though the Standish research shows that the chances of success are much greater with Agile than when using Waterfall, there is still a high chance (58%) that a project will be challenged, failed, or cancelled. Many projects that would have been considered successful using the Standish definitions may have another problem in that they deliver little or no business value. Let’s look at some recent industry quotes on this topic. 78%...
by John Parker | Nov 16, 2012 | Business Analysis, Uncategorized |
The vast majority of IT projects seldom deliver the anticipated returns specified in the business case. Look at the same of the quotes from the sources below. “78% of Information Systems projects failed to realize even 50% of the originally identified benefits.” Source: Management Today “Only 40% of CFOs find that their IT investments are producing the returns they expected.” Source: Gartner, How to Optimize IT Investment Decisions “30-40% of systems to support business change deliver no benefit whatsoever.” Source: OGC, Successful Delivery Toolkit The reasons why benefits are seldom achieved are many. Below is a list of some of the common reasons. The business problem was poorly defined giving rise to a flawed business case. The business case was poorly developed and established an incorrect or unrealistic expectation. Requirements for the solution were inaccurate, incomplete or were poorly defined. Delivery of the solution was poorly executed. The technical solution was fundamentally flawed. The delivered solution was not effectively adopted by the business. The business changed significantly between inception and project completion. Let’s look at what can be done to achieve more benefits. Prepare a realistic and accurate business case. The business case should not just be used to secure funding, but should also be used a management tool to measure success. Section 1 – Problem Statement Section 2 – Vision Section 3 – Alternatives Section 4 – Recommended Strategy Section 5 – Benefits Section 6 – Assumptions Section 7 – Financial Analysis Section 8 – Risk and Mitigation Strategies Change the key measure for determining project success to whether the business benefits as proposed in the initial business case were achieved....
by Karl Wiegers | Oct 19, 2012 | Business Analysis, Uncategorized |
Experienced project managers and developers understand the value of translating software requirements into robust designs and rational project plans. These steps are necessary whether the next release represents one percent or one hundred percent of the final product. This article explores some approaches for bridging the gap between requirements development and a successful product release. In particular, we will look at several ways in which requirements influence designs and code (Figure 1). Figure 1. Requirements drive project planning, design, coding, and testing activities. From Requirements to Designs and Code The boundary between requirements and design is not a sharp line, but keep your specifications free from implementation bias except when you have a compelling reason to intentionally constrain the design. Requirements specification should concentrate on describing the intended external system behaviors. Ideally, the descriptions of what the system is intended to do should not be slanted by design considerations. Practically speaking, many projects contain design constraints from prior products, and backwards compatibility is a frequent requirement. Because of this, a requirements specification almost always contains some design information. However, the specification should not contain inadvertent design. Include designers or developers in requirements reviews to make sure the requirements can serve as a solid foundation for design. A product’s requirements, quality attributes, and user characteristics drive its architecture. Studying a proposed architecture provides a different perspective that helps to verify the requirements and tune their precision, as does prototyping. Both methods use the following thought process: “If I understand the requirements correctly, then this approach is a good way to satisfy them. Now that I have a preliminary architecture (or...
by John Parker | Oct 10, 2012 | Business Analysis, Uncategorized |
This article considers the BABOK Knowledge Area, Solution Assessment and Validation, about which there is much confusion and inaccurate information on the Internet. I have been intrigued by this topic for some time and truly believe it has great potential to deliver significant business value. According to BABOK, the Solution Assessment and Validation Knowledge Area describes tasks performed to ensure that solutions meet business needs and facilitates successful solution implementation. These activities are not just limited to application software, but address a variety of other areas such as business processes, organizational change, outsourcing agreements, and any other component of the solution. The knowledge area consist of six tasks, which are: Assess Proposed Solution Allocate Requirements Assess Organizational Readiness Define Transition Requirements Validate Solution Evaluate Solution Performance Let’s examine three of these areas where significant confusion exists: Assess Proposed Solution, Validate Solution, and Evaluate Solution Performance. The confusion among these areas is amazing. I read one article that described Evaluate Solution Performance as “performing various tests to confirm that the solution meets performance related goals such as response time, availability, and scalability.” Wow—maybe it is time for IIBA to change the name of this task. Other articles seem to think these goals are all the same. Assess Proposed Solution (Pre Solution Acquisition) According to the BABOK, the purpose of Assess Proposed Solution is to “assess proposed solutions in order to determine how closely they meet stakeholder and solution requirements.” After requirements have been defined and prioritized, the proposed solution with its set of requirements is analyzed to determine whether the solution will deliver sufficient business value to justify its implementation....
by Karl Wiegers | Aug 6, 2012 | Business Analysis, Testing, Uncategorized |
Someone once asked me when you can begin testing your software. “As soon as you’ve written your first requirement, you can begin testing,” I replied. It’s hard to visualize how a system will function just by reading the requirements specification. Tests that are based on requirements help make the expected system behaviors more tangible to the project participants. And the simple act of designing tests will reveal many problems with the requirements long before you don’t execute the tests on an operational system. If you begin to develop tests as soon as portions of the requirements stabilize, you can find problems while it’s still possible to correct them inexpensively. Requirements and Tests Tests and requirements have a synergistic relationship. They represent complementary views of the system. Creating multiple views of a system—written requirements, diagrams, tests, prototypes, and so forth—gives you a much richer understanding of the system than can any single representation. Agile software development methodologies often emphasize writing user acceptance tests in lieu of detailed functional requirements. Thinking about the system from a testing perspective is very valuable, but that approach still leaves you with just a single representation of requirements knowledge. Writing black-box (functional) tests crystallizes your vision of how the system should behave under certain conditions. Vague and ambiguous requirements will jump out at you because you won’t be able to describe the expected system response. When BAs, developers, and customers walk through the tests together, they’ll achieve a shared vision of how the product will work. A personal experience really brought home to me the importance of combining test thinking with requirements specification. I once...
