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.
Good business solutions begin with good business analysis. But what's needed to excel as a business analyst and to get projects started on a good footing? Much has been (and will continue to be) said about the set of skills that go to making a good business analyst. Forrester Research, for example, has published a spreadsheet (called the Business Analyst Assessment Workbook -- Note: subscription required) that lists more than 150 attributes of a good business analyst, grouped into categories such as Core Capabilities, Business Knowledge, Job-Specific Skills, Technical Knowledge etc. (I was particularly pleased to see this last category: It is important but not quite obvious that business analysts should also have a rudimentary general understanding of technology environments and architectures… mostly built up through seeing past analysis engagements fructify into delivered solutions).
Although the workbook is obviously intended as an assessment tool, I also found in it good for use as a training tool — for example, to bone up on technology approaches to business needs and to study sample projects, correlating the original business requirement with the type of solution delivered. Here are 10 items from the Forrester list that I found particularly interesting and beyond the obvious (in no particular order)...
Here we are, the end of another year, and the question I ask always is, what have we learned? If we are not learning something, be it from a success or a failure, or something in-between, then how can we move forward?
Information security is something that needs to continuously improve and refine itself, otherwise it will fall behind the curve of those that choose a different avenue to your beloved data store. A tool that information security practitioners often use, especially after a security incident like a virus outbreak or full out attack, is holding a “Lessons Learned” meeting. The core concept is to be able to take something away for the incident, no matter how big or small, so that the next encounter of a similar kind does not have the same result as the first.
In this article, I describe one very effective collaborative technique -- the Wall of Wonder (WoW) -- that helps software teams produce the kind of detailed, sharply defined requirements that effectively guide development. As an "emergent" deliverable, requirements evolve through exploration and examination using representative forms such as low-fidelity models and prototypes. A collaborative approach allows business and IT specialists to explore their requirements through these means, while accommodating the necessary fluidity of the requirements process.
As an analyst practitioner I took it upon myself to act as a proxy for the product owner – which in a corporate environment came with the challenges of multiple stakeholders, the fact that you are not the product owner and thus don't really have the final say, and a number of other challenges that typically stump people trying to move to agile. My circumstances were unique in some ways. I had worked in the organisation for some time and had established good relationships with all the key stakeholders. They really did trust me with their requirements because, over time, I had learnt (and shown I had earned) their business. I also maintained high bandwidth communications with the stakeholders throughout the project and kept them informed of what was happening and how the system was shaping up in the context of their business needs. And expectations were managed.
A lot of IT folks and or BA’s believe that if you create the requirements without the business, and then review the requirements with the business for confirmation, you can save a lot of time. After all, creating requirements collaboratively just takes too long, and the business doesn't know what they want, anyways. In addition, we (IT or BA) know the system better than the business, so it just makes sense for us to create the requirements, and then let the business say yes or no. Let’s see this concept in practice in the “Requirements for My New Car”: a fable.
My friends and colleagues often ask me how I am able to produce so much in so little time. Although I am flattered by such compliments, it's really not much of a secret which I attribute to the following areas (in no particular order):...
Author: Tim Bryce
In today's market the customer should always come first. This has been the bread and butter of many industries throughout the ages. A satisfied customer is one who will keep coming back. The customer is the one who helps the bottom line. This is true in the field of business analysis. It is the customer's needs which the business analyst is fulfilling. The business analyst should help to strengthen customer relations. Time put into this is time well spent. Finding the customer to be unhappy is never a good thing. Ask any good business manager what their number one priority is and they will answer customer relations. Sometimes it does not always show.
Author: Tony de Bree
Small business owners may not think they need a business analyst. Small businesses are sometimes caught up in trying to survive and overlook a key element in their success. The business analyst can actually come in and determine what the small business owner can do to expand his or her business. The small business owner can benefit just as much from a business analyst as a large corporation. There may be times when the business analyst sees the big picture when the small business owner can only see the bottom line. The new small business may not feel the added expense of a business analyst is worth justifying. In fact this is just the case.
Sometimes the business analyst can be so caught up in a project he or she forgets tried and true methods do not always work. The analysis team is trying to get done what the customer has scoped out and sets up a plan of action. The plan of action requires certain fundamentals. There are times when these rudimentary ideas just do not work for the client. The client can not understand why these steps may be so important. This is when the business analyst needs to step back and ask the same questions as the client. It is all in communication.
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: