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’
Archive for October, 2009
Embracing the Change Request by Patrick Bowe
Published October 31, 2009 02 - Analysis Phase , Business Analysis , Project Lifecycle 1 CommentTags: Change
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’
What does a Business Analyst do? – by Patrick Bowe
Published October 8, 2009 Business Analysis , Project Lifecycle 5 CommentsTags: Definition, Project Phases, Role, Skills
Something that I’ve actually been asked while pitching for work is “What does a Business Analyst actually do?”. While I won the work in that instance, I was never happy with the answer that I gave at the time. I managed to babble something out about how a BA was the bridge between IT and the business and while this is true, it hardly demonstrates what I could do to impact the bottom line of a project.
Since then I’ve relayed this story many times, only to discover that it wasn’t just my erstwhile interviewer that was unsure of what a Business Analyst actually does. Very often it’s not until a BA has delivered on a piece of work that the business that they are working for appreciates exactly what it was that the BA did for them, even then I suspect they would find it difficult to define exactly what it was that the BA did. Continue reading ‘What does a Business Analyst do? – by Patrick Bowe’
