The Community Blog for Business Analysts

Entries for 'David Wright'

 I keep seeing in BA skill descriptions or in specific articles that ‘negotiation skills’ are a necessity for Business Analysts. I just don’t see it myself. Negotiation is a difficult activity for many people, and I see this trend as an attempt to offload negotiation to other people… like Business Analysts. Why do I feel this way? As an activ...
1 Responses
This entry was published on Sep 12, 2013 / David Wright. Posted in Business Analysis, Analytical and Problem Solving Skills, Roles and Responsibilities. Bookmark the Permalink or E-mail it to a friend.
Agile is an attractive word. It means swiftness with discipline, with an emphasis on alertness to change in one’s external surroundings and quickly responding to change as needed. The word I want to focus on from above is "external". A prime example of the difference between internal (controlled) and external (un-controlled) is an operating enter...
1 Responses
This entry was published on Apr 29, 2013 / David Wright. Posted in Business Rules, Agile Methods. Bookmark the Permalink or E-mail it to a friend.
For those of you who do define requirements for their software development projects, but are new to buying packages, a cautionary warning; they are not the same thing. Consider the following “the system shall” requirement  statements.   1) The system shall determine if a person ordering pizza is a current customer. 2) The system shal...
0 Responses
This entry was published on Feb 08, 2013 / David Wright. Posted in Elicitation (BABOK KA), Requirements Analysis (BABOK KA) . Bookmark the Permalink or E-mail it to a friend.
In the wide world of information systems, development of new software receives the most attention from industry writers. Whether it is traditional magazine articles and books, or blog posts, or discussions in groups on LinkedIn and other sites, it is all about “green field” development. However, when one considers the wider view of organizations c...
0 Responses
This entry was published on Dec 30, 2012 / David Wright. Posted in Requirements Analysis (BABOK KA) . Bookmark the Permalink or E-mail it to a friend.
  People expect a lot from their information systems, but it usually it comes down to one thing: the system has to do stuff. When you talk about systems, the verbs are active: the system is running, it is executing a function, the system is responding, ....   And what do you want it to do? You want it to do as much of your business p...
1 Responses
This entry was published on Sep 01, 2011 / David Wright. Posted in Business Analysis. Bookmark the Permalink or E-mail it to a friend.
Let me reprise the words of Mr. Brooks ... “… the hardest single part of software development [remains] deciding precisely what to build." Fred Brooks Author of the 1986 paper "No Silver Bullet” The unspoken corollary to this is you have to be sure you don't build the wrong system. Knowing what and what not to build is a matter of definin...
0 Responses
This entry was published on Aug 24, 2011 / David Wright. Posted in Business Analysis. Bookmark the Permalink or E-mail it to a friend.
Back to the nasty question - what sort of Information System shall will we build? "What sort of system do you want?" "hmmm, one that processes all our customer orders, I think. What do you think, George?" "Well Fred, I suppose so, but I know it has to be fast, and run 24/7." "OK.........(???)" We already know the problem with asking people...
1 Responses
This entry was published on Aug 16, 2011 / David Wright. Posted in Business Analysis. Bookmark the Permalink or E-mail it to a friend.
Software is a uniquely new invention, different than anything else we humans have come up with in the past. ... "The software-controlled electronic information system is fundamentally different from physical labor-saving devices such as the cotton gin, the locomotive, or the telephone. Rather than extend the ability of hand motion, leg motion, ...
0 Responses
This entry was published on Aug 10, 2011 / David Wright. Posted in Business Analysis, Leadership & Management. Bookmark the Permalink or E-mail it to a friend.
Information Systems Users don't know what they want... So, don't ask them what they want: and definitely don't write some software and then say "how's this look?". On the other hand, don't have someone spend weeks talking to various people about what they want ( and not get to talk to other people ), write it all down and deliver a document, sayin...
1 Responses
This entry was published on Aug 06, 2011 / David Wright. Posted in Elicitation (BABOK KA), Business Analysis. Bookmark the Permalink or E-mail it to a friend.
What do you need the most when eliciting Requirements? Face-time with Subject Matter Experts and their Managers.  As a Business Analyst employed in a typical organization, what is the thing you get the least of? Face-time with Subject Matter Experts and their Managers. Who will Subject Matter Experts and Managers make time to see? Outside Cons...
0 Responses
This entry was published on Apr 28, 2011 / David Wright. Posted in Elicitation (BABOK KA), Business Analysis. Bookmark the Permalink or E-mail it to a friend.
Who owns a project?   “You pay for it, it’s yours.” I am sure I am quoting (or misquoting) someone here, but you get the idea. For an IT project of any size or worth, someone senior enough to be an effective sponsor is usually desired, along with the budget to ‘pay’ for it. I put ‘pay’ in quotes because all the dollars spent on a projec...
0 Responses
This entry was published on Mar 12, 2009 / David Wright. Posted in Project Management, Leadership & Management. Bookmark the Permalink or E-mail it to a friend.
I am now lucky enough to be working at a consulting company with a great group of experienced people, and we do share some great "war stories", and it made me think that I do have my share of experiences that, if written down, some small number of people may find interesting.  Seems to me a blog is great for that. I would call this memories r...
0 Responses
This entry was published on Jun 19, 2008 / David Wright. Posted in Career as a Business Systems Analyst. Bookmark the Permalink or E-mail it to a friend.
Thirteen is all you need, at least in this point in time. I may add to them as time goes by, but I would also like to hear from readers if they have any suggestions or thoughts or their very own principles for IT Projects success. Pleae offer them and maybe we can get them into the second edition of the book...which you all remember is available at...
0 Responses
This entry was published on Jun 17, 2008 / David Wright. Posted in Systems Analysis, Business Analysis. Bookmark the Permalink or E-mail it to a friend.
13. Given many medium to small software Deliverables, use Architecture to manage and integrate the Deliverables into a complete system. This is a more specific statement of Principle #3; in Cascade, an Information System Architecture is used to integrate the two week deliverables, until a complete deliverable (component, sub-system) is assemble...
0 Responses
This entry was published on Jun 13, 2008 / David Wright. Posted in Systems Analysis. Bookmark the Permalink or E-mail it to a friend.
12. Within the three month phase, parcel work into two-week periods; analyze for 2 weeks, then design and develop for 2 weeks (two developers), and then test for 2 weeks. When the first 2 weeks of analysis is done, start the next two weeks of analysis in parallel to the design/development; carry on in cascading 2 week periods until the entire proje...
0 Responses
This entry was published on Jun 09, 2008 / David Wright. Posted in Systems Analysis. Bookmark the Permalink or E-mail it to a friend.
#11.   Partition large projects into 3 month phases, that is the longest period you can plan for without the chance of significant change to priorities, resourcing, etc. I was lucky to learn this early in the 90's as Project Management was getting a higher profile, accompanied by the increased use of Microsoft Project. Other PM tools wer...
0 Responses
This entry was published on Jun 05, 2008 / David Wright. Posted in Systems Analysis. Bookmark the Permalink or E-mail it to a friend.
#10. Models are better than text. I would like to think that by this point in time, this principle no longer requires justification. It has been at least a few years since I last saw a dense “SRD” or “SDD” document (SYSTEM REQUIREMENTS DOCUMENT, SYSTEM DESIGN DOCUMENT).  I must offer my respect to the many talented people who labored to produ...
0 Responses
This entry was published on Jun 02, 2008 / David Wright. Posted in Systems Analysis. Bookmark the Permalink or E-mail it to a friend.
#9. Leave a record of what you have done, so the project will not miss you if you leave. If change is the only constant, then resources on a project will change. The risk in such change is that a person’s contribution to a project will be lost, and that the new person assigned to the project will have to start over. This is a particular risk in...
0 Responses
This entry was published on May 29, 2008 / David Wright. Posted in Systems Analysis. Bookmark the Permalink or E-mail it to a friend.
#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.
#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.
Page 1 of 2First   Previous   [1]  2  Next   Last   


Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.



Modern Analyst Blog Latests

Jarett Hailes
Jarett Hailes
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-...
2 Responses
Howard Podeswa
Howard Podeswa
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...
11 Responses
Adrian M.
Adrian M.
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
2 Responses
Featured Digital Library Resources 
Copyright 2006-2015 by Modern Analyst Media LLC