Of all the challenges faced by a business analyst, Poor Requirements, Changing Requirements, Scope Creep, Changing Deliverables, Changing Expectations, I believe that poor requirements are probably the most severe issue that can be faced by a project. Continue reading ‘Dealing with Poor Requirements’
Archive for the '02 – Analysis Phase' Category
Dealing with Poor Requirements
Published February 22, 2010 02 - Analysis Phase , 04 - Testing Phase , Business Analysis , Project Lifecycle , Techniques Leave a CommentTags: Change, Project Phases, Requirements, Role, Test
Creating a Change Request by Patrick Bowe
Published November 26, 2009 01 - Initiation Phase , 02 - Analysis Phase , 03 - Development Phase , 04 - Testing Phase , 05 - Implementation Phase , BA Skills , BA Tools , Business Analysis 3 CommentsTags: Change Board, Change Request, How To, Skills
“It is not necessary to change. Survival is not mandatory”~ W. Edwards Deming
I’ve discussed in a previous post how it’s the role of the business analyst to seek out and embrace change. However change is often chaotic, expensive and unless you happen to be the stakeholder sponsoring the change, it’s usually about as popular as a tester at a developer’s convention.
As enthusiastic proponents of change, our challenge as Business Analysts is to sell the need for change to sceptical stakeholders and budget holders alike and also to point out when a change is neither desirable nor in the best interests of a project.
Enter then, the humble Change Request, a BA’s most trusted tool in the change process. A tool that allows the Business analyst to detail what the specific business problem is that caused the need for a change, what can be done to resolve the business problem and what impact those changes will have on a business or project. Continue reading ‘Creating a Change Request by Patrick Bowe’
Embracing the Change Request by Patrick Bowe
Published October 31, 2009 02 - Analysis Phase , Business Analysis , Project Lifecycle 1 CommentTags: Change
Change Requests are the inevitable consequence of trying to document requirements and to fulfill the needs of others. Minimising the number of change requests on any given project is an admirable goal, but eradicating them all together is never going to happen and is probably going to be detrimental to your project. Continue reading ‘Embracing the Change Request by Patrick Bowe’
5 Ways to Improve your Requirements by Patrick Bowe
Published October 22, 2009 02 - Analysis Phase , BA Skills Leave a CommentTags: Requirements, Skills, Tips
“Deficient requirements are the single biggest cause of software project failure.”
(Hofmann and Lehner, 2001)
We’ve probably all been on a project where the requirements have been deficient or where the business has articulated a solution instead of a need. As an example, a requirement that I’ve often heard articulated on projects in the past has been; “The solution must be delivered via the Intranet”. This appears to the business to be a very clear requirement and, if left unchecked, it’s what the development team will eventually deliver.
However, is it what the business actually needs? Why did they request a web site? Did they want to avoid the need to install software on client machines or was it to reduce the processing that has to be done on the end user’s laptops. If so the project will either fail or become much more expensive if all the computers in an organisation need to have the flash player installed for the Intranet site to run or if all the processing is done on the client machine to reduce the stress on the web server.
Projects with requirements that are clearly deficient, such as the one above, are doomed to failure as Hofmann and Lehner stated, so it’s important that the person gathering the requirements, the Business Analyst, ensures that they are accurate and clearly articulate a business need. The following five tips cover areas where requirements usually fail and offer advice on how you might improve your requirements:
1. Improve the Clarity of your Requirements
Defining requirements is a tricky business. In my experience the business owner will either not read them or go through them word by word looking for ambiguous requirements, hoping that they will give them a get-out clause or room to negotiate change at a later stage of the project. Continue reading ’5 Ways to Improve your Requirements by Patrick Bowe’
