Processes are the user interface to a solution – as such they are highly visible and a lot of project effort is focussed on process modelling. In fact, there is a perception in some quarters that Business Analysts just draw process models and this is all they do. However, process models (the drawings of processes) are only one facet of the specification of a process.
Have you ever thought the following thought while describing business processes? A decent percentage of the work business analysts (BAs) do is repetitive in nature. Business rules define the various subject matters, different businesses, or just differences in doing business. Just recently, I have again used a use case approach to a business process reengineering (BPR) problem. The aim was restructuring along natural business module borders, so that different applications (new and existing ones) can handle the business process more efficiently, more secure and within the right stakeholder's responsibilities. As almost always, documentation of the business processes had undergone aging as well.
Before starting, it is important to understand process mapping’s place in the larger context of business process improvement. Improving your process typically starts with documenting how it works today, what we call the “as-is” process.
In this article, I'll be discussing some other requirements gathering methods that complement use case modeling and should be used to ensure your requirements gathering goes swimmingly. In particular, I'll be mentioning storyboards, wireframes and prototypes. I'll also cover what level of quality and detail you should adopt when applying these techniques.
Not unlike gardening, Enterprise Analysis takes very careful stock and consideration of the current state of your environment. By IIBA® definition, Enterprise Analysis is:
The reason is simple, anyone involved in Information Security needs a detailed understanding around how things work; where the dependencies are, the inner workings of programs and applications, who has administrative control over sensitive information, where the information is being stored, and how clients and programs interact with the data. Performing threat risk assessments (TRA) involves an intimate understanding of a solution or service. This means everything from the pretty UI right down to the bits of code your development team scribed to make it look that way. The only way to understand these systems is via detailed communication with stakeholders, architects, business analysts, systems and network administrators, executives, clients and their technical resources, board members, vendors, ISPs, and the list goes on.
There are great shifts that happen in technology and culture. Sometimes they occur sequentially, as WWII created a need for advanced computing, and the PC forever changed the nature of work. Sometimes they happen concurrently, where pressures, both positive and negative, take place in tandem. We are in such a time of change now, with great crises and great opportunities for organizations and the people who love them. One of these challenges is the failure of Enterprise, Business and Technical architecture. Why do the Three Stooges so often stumble and fail?
When ModernAnalyst asked me to propose an article for their issue on Enterprise Architecture, I thought about the question framework developed by John Zachman, that provides the basic building blocks of that practice. The primary function of a Business Analyst is to ask questions that uncover requirements then to document those requirements so they may be developed into a useful, useable system.
As budgets tighten and organizations continue trying to achieve return on investment faster, cheaper and with better results, they are trying to create and evolve their overall enterprise architecture.
If the object you are trying to create is so simple that you can see it in its entirety at a glance and remember how all of its components fit together at excruciating level of detail all at one time, you don’t need Architecture. You can "wing it" and see if it works. It is only when the object you are trying to create is complex to the extent that you can’t see and remember all the details of the implementation at once, and only when you want to accommodate on-going change to the instantiated object, that Architecture is IMPERATIVE. Once again, without Architecture, you are not going to be able to create an object of any complexity and you won’t be able to change it (that is, change it in minimum time, with minimum disruption and minimum cost).
Two years ago, some of my friends pressed me intensely to be more definitive about the Framework concepts. Even though, I had written “The Book”, they were specifically asking me for definitions of the entities that comprise the metamodel of Row 2 of the Enterprise Framework. It has taken me and a team of dedicated folks two years, however we have progressed far beyond the original requirement.
In recent years it has become more and more apparent that the job description of Business Analyst has become diluted and distorted. Can this be considered the natural evolution of a profession or is it a profession that no longer has a clear job description? Is this a profession that has moved past the point of clear boundaries or are the boundaries still there but blurred based on the need to adapt to a changing world to meet the needs of people rather than the needs of the business? What can we do to win back the respect that the Business Analyst profession deserves? Exactly whose responsibility is it to maintain a professional and respected image of this profession? Should the recruitment process of Business Analysts be an exercise in requirements gathering?
If it is allocating your internal resources, making a new hire, or bringing in a consultant; what is the best process to match the right business analyst to the right project? For organizations that truly value the role of the business analyst this is one of the most frequently pondered questions.
Companies that want to have the right people in the right roles need to address four main stages; defining the BA’s roles in the project, attracting the best talent, matching the BA to the project and finally, making the selection and continuing to support.
As an agile analyst, you know how easy it is to get lost in a blizzard of project details. The way to keep focused is to remind yourself of the chief reason for using agile processes: to deliver business value for your organization. With that in mind, we’ll look at specific ways you can combine two approaches: agile and lean.
When I’m not consulting or managing projects, some of my time is spent teaching MBA classes at Drake University. The fact that I teach both project management AND creativity for business creates consternation among some of my friends and colleagues. After all, can a project manager really be creative? Aren’t those mutually exclusive skills?
My response is a great project manager also must excel at creativity to remain a viable, valuable asset in today’s marketplace. Gone are the days of simply managing scope within a budget and schedule; project managers must be multi-faceted utility players. Project and program managers are being expected to create solutions, to facilitate conflicts, and to motivate resources toward a goal in ways never before anticipated.
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: