Working on a new application? You never really know how it will go over until it rolls out. No matter how detailed a wireframe may be, no one can completely picture it in action until they experience the real thing—hours of detailed coding and all. With Prototyper 4.6, your wireframe prototypes look, feel, and behave just like your final application, giving stakeholders and potential users the full experience of the application before any coding even begins.
In this four part series, I will give you the confidence and motivation you need to make a difference; a difference that will allow you to “Bark with the Big Dogs.” What I’m about to share is tried, tested and true. There are no gimmicks. Before you read on, ask yourself this: “Am I willing to try something different?”
I was recently working with a client who said that the life of a BA in his organization is complicated, primarily because very few people really understand what Business Analysts (BAs) do. I have felt for a very long time that perhaps our most compelling challenge is to change the organizational view of our role as primarily “requirements collectors” and to help stakeholders see the true value that business analysis brings to the enterprise.
While many organizations have already adopted The Decision Model, others are actively exploring how it may improve or totally replace their current business rules approaches. The latter are asking the critical question: How is The Decision Model different from what we are doing and why are these differences important?
Many run into the problem of differentiating between a systems analyst and a business analyst. The differences in some organizations do not exist. In other companies, the comparison is almost an insult. Depending on the business or corporation, there are many differences. The job title is not the only thing with which to compare these two separate roles. The problem occurs when the title is not so conclusive. The business systems analyst or the systems business analyst can actually be one or the other or both. Job description is the only way to tell when this happens. There are differences, though.
Author: Tony de Bree
I learned this in a virtual meeting where about 10 stakeholders were invited to give input to a mock-up created by our project. They were all subject matter experts within the area, and had earlier provided some input on an individual basis. I walked through the whole thing, and what happened? There were no comments or suggestions. I couldn't believe it. I know that subject matter experts always have an opinion.
If you’re looking to manage business activities on a business-process basis, stability is key. But business rules aren’t stable. In fact, many change quite rapidly. What should you do? Separate the business rules from the business process model, so the business process model can do its job.
You walk into your local IIBA meeting and introduce yourself to a new attendee. They ask you what seems to be one of the toughest questions in the world: “How do I become a business analyst?” Hmm… How do you become a business analyst?
I’ve written in the past about why hybrid approaches that incorporate traditional and agile methods of software development are been applied by organizations seeking to improve the results of their software projects. Here I’ll describe the 3 types of hybrid projects I have identified while working with different organizations in consulting assignments, and what impact each type has in the work of a business analyst.
brought to you by enabling practitioners & organizations to achieve their goals using: