by George Casey | Aug 20, 2012 | Business Analysis, Uncategorized |
Enfocus Solutions Inc. has teamed up with Karl Wiegers to bring you a requirements management educational video series. The videos delineate all aspects of requirements management, from simple concepts (“What Is a Requirement?”) to detailed explanations of industry standards (“Version Control”). Video Synopsis We can organize our thoughts about requirements with a three-level model. The top level respresents business requirements – why are we taking on the project? The second level represents user requirements – whiat will the users be able to do with the system? The third level represents functional requirements – those that help users get their jobs done (what does the developer build?). Respectively, the three documents often associated with the levels are a Vision and Scope document, a User Case, and a Software Requirements Specification (SRS). If you implement accurate functional requirements, your project should meet the user requirements and business requirements quite effectively. Watch the Karl Wiegers video...
by John Parker | Aug 9, 2012 | Agile, Business Analysis, Uncategorized |
Agile projects are successful three times more often than Waterfall projects, according to the 2011 CHAOS Manifesto from the Standish Group. The report indicates “The Agile process is the universal remedy for software development project failure. Software applications developed using the Agile process have three times the success rate of the traditional waterfall method, and a much lower percentage of time and cost overruns.” The Standish Group defines project success as a project that delivers on time, on budget, and includes all planned features. Even though the Standish research shows the chances of success are much greater with Agile than using traditional Waterfall methodology, there remains a high chance (58%) that a project will be challenged, failed, or cancelled. Let’s examine some reasons why Agile projects may have problems. Poor Stakeholder Communication Poor communication between stakeholders and IT is a common downfall of any project; Agile projects are not exempt. Poor communications can result at several levels including product owner to stakeholder, product owner to team, and even team to team. Unfortunately, stakeholders are frequently not be clear about what they expect from team members. Requirements and Specifications are Incomplete or Not Clear A major cause for failed Agile projects is that the requirements have not been thoroughly defined. Agile classes teach us to garner user stories; you are also taught to elaborate user stories with test cases and conversations. Many teams seem to forget the test cases and conversations. I have seen this as a major problem on many projects. To avoid having a project with incomplete requirements, or an abstract scope, take the time to carefully define...
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...
by John Parker | Jul 17, 2012 | Business Analysis, Uncategorized |
This is the sixth 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. Most modern software development methodologies employ some form of iterative and incremental development. This is certainly the case with all of the agile development methodologies. In general, the iterative development model allows for early adjustments to the product design during development, rather than finding the problem once it is too late and having to spend a great deal of time and money trying to incorporate the changes into the project after it is fully operational. You are provided the chance to see the potential outcomes of every stage and make necessary changes to areas of concern. This is one of the reasons the iterative model useful. In the iterative development model, corrective actions are normally done at every interval; they are highly accurate and specific. This is because if there is a fault in the requirements or design stage then it can hopefully be found sooner rather than later. These corrective measures are also effective as they reflect the outcome of the specific stage of the project. Iterative development is more adjustable to changes as it considers each stage like a vital portion of the development cycle. The time spent on each successive interval may be lessened depending on how well the last stage went and the knowledge was gained from past stages. The system therefore grows through adding new functionalities in the development part of each iteration. Furthermore, since all iterations tackle a small requirement set, time is...
