Business Analyst Community & Resources | Modern Analyst

The Community Blog for Business Analysts

David Wright

Cascade Day 10 - Principle #8: It’s the Deliverable (that matters), not the Task

#8 --> It’s the Deliverable (that matters), not the Task. The final deliverable is the Information System ready to be used effectively by the Business. If you can jump from ‘Start’ to this final deliverable in one “Task”, then power to you. Some people can do this; most cannot. This is again where a team of specialists is most effec...

0 Responses

This entry was published on May 28, 2008 / David Wright. Posted in Systems Analysis. Bookmark the Permalink or E-mail it to a friend.

David Wright

Cascade Day 9 - Principle #7: One Architect/Analyst can generate enough work for two Developers and one Tester, structure your project teams in this ratio.

#7 One Architect/Analyst can generate enough work for two Developers and one Tester, structure your project teams in this ratio. This is actually one of those “rules of thumb” that have been borne out over time. (The ratio may vary a bit from case to case, like when the experience levels are different across the roles.) This ratio combines with...

0 Responses

This entry was published on May 27, 2008 / David Wright. Posted in Systems Analysis. Bookmark the Permalink or E-mail it to a friend.

David Wright

Cascade Day 8 - Principle #6 - Specialize – each member of a team assigned to a project should do what they do best for the length of that project.

This principle supports #5. With limited resources, there is another strong tendency to have IT staff ‘wear multiple hats’ on a project, especially the Business Analyst who is asked to also be the Project Manager and/or Lead Tester. Rather than getting more than you are paying for, you get less as an IT Staffer skilled in one role spends more time ...

0 Responses

This entry was published on May 22, 2008 / David Wright. Posted in Systems Analysis. Bookmark the Permalink or E-mail it to a friend.

David Wright

Cascade Day 7 - Principle #4 - Pick the right project(s) for the business

Principle #4 - Pick the right project(s) for the business. At any one time, the IT department of an average company is running multiple projects. How did they get started? How were they even defined as a project that needed to be carried out? No one may actually know. In more chaotic environments, projects can start as a seed of an idea, pic...

0 Responses

This entry was published on May 21, 2008 / David Wright. Posted in Systems Analysis. Bookmark the Permalink or E-mail it to a friend.

David Wright

Cascade - Day 6 - Principle #3: Use Architecture to describe the business, before and after projects.

Principle #3: Use Architecture to describe the business, before and after projects. “Architecture” is becoming a more widely used term associated with Information Technology. The number of adjectives applied to the term seems endless: “Technical Architecture”, “Systems Architecture”, “Business Systems Arch...

0 Responses

This entry was published on May 20, 2008 / David Wright. Posted in Systems Analysis. Bookmark the Permalink or E-mail it to a friend.

David Wright

Cascade - Day 5 - Principle #2: Projects change the business, so know the overall business first

Principle #2: Projects change the business, so know the overall business first A never-ending discussion in IT circles is about how much IT staff need to know about the business that the information systems are supporting. It is high-lighted by every want-ad for an IT job that says previous experience in the employer’s industry is mandatory. Is d...

0 Responses

This entry was published on May 16, 2008 / David Wright. Posted in Systems Analysis. Bookmark the Permalink or E-mail it to a friend.

David Wright

Cascade - Day 4 - Principle # 1: There is always more work to be done than people to do it.

Let’s look briefly at what each principle means or implies; which will serve as introductions to subsequent posts that will cover the principles in more detail. #1. There is always more work to be done than people to do it. Bordering on glibness, this principle summarizes the reality of virtually all organizations and activities, not just Informa...

0 Responses

This entry was published on May 15, 2008 / David Wright. Posted in Systems Analysis. Bookmark the Permalink or E-mail it to a friend.

David Wright

Cascade - Day 3 - Principles

Like you, I have read my fair share of IT books and blogs, and each author has to decide how to best present what they are trying to communicate. One way is to describe the problems/opportunities of interest to the reader, then document the new approach or method that solves the problems, etc.; the reverse is to document the new approach/method fir...

0 Responses

This entry was published on May 14, 2008 / David Wright. Posted in Systems Analysis. Bookmark the Permalink or E-mail it to a friend.

David Wright

Cacscade - Day 2 - what can you do to be successful?

The premise of these blog entries is that the situation described in the previous post can change, but it is usually slow-going; or worse, there can be an immediate channge when your department is outsourced; it happens. In the meantime, what can be done to be “successful” in your average IT department in your average company? What has to be do...

0 Responses

This entry was published on May 09, 2008 / David Wright. Posted in Systems Analysis. Bookmark the Permalink or E-mail it to a friend.

David Wright

Cacscade - Day 1 - does this sound like where you work?

Day 1: I have recently made a major career change, moving from what I would now call a client company to a consulting company. It's an exciting change, but I don't expect to write about my new experiences at this time. However, I had also been spending some time writing an extended piece about my experiences over the years working ...

0 Responses

This entry was published on May 08, 2008 / David Wright. Posted in Systems Analysis. Bookmark the Permalink or E-mail it to a friend.

Page 34 of 36

First Previous 27 28 29 30 31 32 33 [34] 35 36 Next Last

Modern Analyst Blog Latests

Jarett Hailes

Three Audacious Goals for Business Analysts in 2013

As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...

Howard Podeswa

Hey IIBA, What’s Up With That?

Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...

Adrian M.

BA ABCs: “C” is for Class Diagram

Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN