1 Articles match "2007","Business Analyst"

6 Articles match "2007","Business Analyst"

• The Best from DevelopMentor

  MORE

• Failures in Agile process?
  
  One downside is that the Product Owner role – typically filled by a Business Analyst, Product Manager, Customer or other proxy-customer – is given an immense work load. However when I thought about this I don’t think the failure is a failure of Agile, I think it is a failure of the business. One of the questions that was posed at ACCU conference was “What are the downsides of Agile development?” rdquo; – and “What does Agile failure look like?”
  Allan Kelly's Blog - Sunday, April 22, 2007
  READ MORE
• IT: Better to be effective or aligned?
  
  Like the Rettig piece they are concerned with internal IT projects rather than products for sale (my main area of interest and experience.) From this survey they are able to divide companies into four categories - a nice 2x2 matrix based on whether a company has effective (or ineffective) IT and whether the IT is aligned with business strategy (or pursuing its own.) These four categories are: IT Enabled Growth : These companies have highly effective IT groups who are closely aligned to the business. In my last blog entry promised to discuss a second piece from the MIT Sloan Review .
  Allan Kelly's Blog - Saturday, December 1, 2007
  READ MORE
• Debunking some myths about Agile
  
  Last week a comment arrived on my Failures in Agile process entry from April 2007. To find this project you need to a) be able to deliver, b) actually deliver business value. • ”all developers must be higly skilled (no learning moments are allowed)” First part: Highly skilled developers help any project go better. The original XP project, C3, did cause the near nervous breakdown of the first “Customer” - Business Analyst or Product Manager really which was a failure in C3. I think I get quite a few comments on this blog and I publish most of them. Almost all
  Allan Kelly's Blog - Sunday, September 14, 2008
  READ MORE
• Software requirements and strategy
  
  A few weeks ago I wrote about the role of requirements in software development, and then I wrote about business strategy. If you lack either you might still go through the motions of developing software but it is unlikely that it will meet market or business needs, and it is unlikely you will have a successful product. These people may be called Product Owners, Business Analysts or Product Managers, what ever, someone has to decide what is in the product I have been on holiday for the last week so it has taken me some while to get around to linking my last blog entries.
  Allan Kelly's Blog - Monday, September 3, 2007
  READ MORE
• Requirements: A dialogue not a document
  
  When developers have to guess it is the business which suffers. What needs doing (the requirements) always needs to be rooted in what the business or market wants and needs. One of these people needs to be the owner of the requirements, these may be called the Product Manager, the Product Owner, a Manager or a Business Analyst. The important point is there needs to be someone who is charged with having these dialogues and ensuring a consistent view emerges. I’m not a lover of requirements documentation. I’ve discussed this at length before - see Why Do Requirements
  Allan Kelly's Blog - Sunday, August 12, 2007
  READ MORE
• Feeling sorry for EDS - business that don't know what they want
  
  I don’t know the rights and wrong of the case, what I do know is that businesses frequently don’t know what they want. Companies with their own IT groups often get into this mess, the business can’t tell the IT people what they want. Well there are two parties here and both need to be involved. The business side needs to set the overall goals - ‘build a state of the art customer service system to produce competitive advantage’. It is not often I feel sorry for EDS. Early in my career I had contact with EDS and I was not impressed.
  Allan Kelly's Blog - Tuesday, October 23, 2007
  READ MORE