Skip to main content

Tag: Business Analysis

Estimating the Business Analysis Phase of a Project. Is it Even Possible?

Written by Elizabeth Larson on . Posted in Articles.

Years ago I worked on a large effort to reengineer a distribution center for a major retailer. We provided an estimate for both the business analysis work and for the entire project, which would involve the organization’s first use of Electronic Data Interchange (EDI), new business processes, many software changes, and the purchase of new barcode scanners. The business analysis effort took far longer than we anticipated, and at the end of it we refined our estimate for the total project. When we reported the new estimate to the president of the company, he literally pounded his fist on the table and asked, “How did we get to this point? Why didn’t we know sooner? You’ve already spent all this time on the project and what do we have to show for it? Nothing! Absolutely nothing!”

I have always thought of business analysis as the most ambiguous and the most fun of the project phases (by phase I mean phase, increment, or iteration). However, for many years it was my least favorite phase to estimate. I felt like I was guessing, simply pulling numbers out of the air. No wonder we were so far off.

Estimating the business analysis phase(s) is not easy. It is not hard, but it takes a willingness to think about exactly what work will be produced, and many business analysts do not have the patience. So for those of you who do not have the “stomach” to spend the required time to estimate business analysis, here are some tips.

  1. Break the effort into manageable pieces. We can estimate a whole lot better when our business analysis phase(s) are small.
  2. As we progressively elaborate our requirements, we can progressively elaborate our estimates. We go from Rough Order of Magnitude (ROM) to budgetary (deliverables identified) to definitive (requirements defined to a low level of detail).
  3. It is helpful to use a variety of estimating techniques. When we’re first asked how long business analysis will take, we really cannot be precise. We use analogous estimating, or experience with a previous project. If we have good history, we might be able to use parametric estimates. For example, if we know that it takes two hours to model a business process and we have five processes to model, it will take ten hours to model business processes. Providing detail on each of these techniques is beyond the scope of this blog, however.
  4. I have found it helpful to brainstorm with the people who are actually going to do the work. They usually have a more realistic idea of what needs to be done and how long it will take. I also like yellow sticky notes, since they can be easily added, taken away, and moved.
  5. But here’s the real key to estimating business analysis. Identify all the deliverables (work products, artifacts) you will produce during the business analysis effort. It is essential to first identify the approach you’re going to take, whether plan-or change-driven (Waterfall/Agile). It is also helpful to use the BABOK knowledge areas to identify which work products will be completed. During the course of an Elicitation event, for example, we might send out an agenda (one work product), update our traceability matrix (another deliverable), create an “as-is” process model (another deliverable), and update our list of issues (yet another deliverable). Next we think of the tasks needed to complete each work product, and finally how many hours the task will take.

Of course the real, real key is having the courage to communicate bad news. Which brings me back to the president pounding his fist. What I should have done was reported the plan vs. actual of the business analysis effort regularly, rather than surprising him after months of work.

What a lesson learned!

Elizabeth Larson, PMP, CBAP, CEO and Co-Principal of Watermark Learning (www.watermarklearning.com) has over 25 years of experience in business, project management, requirements analysis, business analysis and leadership. She has presented workshops, seminars, and presentations since 1996 to thousands of participants on three different continents. Elizabeth’s speaking history includes, PMI North American, EMEA, and Asia-Pacific Global Congresses, various chapters of PMI, and ProjectWorld and Business Analyst World. Elizabeth was the lead contributor to the PMBOK® Guide – Fourth Edition in the new Collect Requirements Section 5.1 and to the BABOK® Guide – 2.0 Chapter on Business Analysis Planning and Monitoring. Elizabeth has co-authored the CBAP Certification Study Guide and the Practitioner’s Guide to Requirements Planning, as well as industry articles that have been published worldwide. She can be reached at [email protected]

Combining Productivity with Creativity

Written by John Dean on . Posted in Articles.

If I may state the obvious, high productivity is good; low productivity is bad. That applies both to individuals and to projects. A number of factors affect individual productivity. Internal factors such as a person’s basic sense of self worth and the amount of discipline they bring to the workplace directly affect their output. Workplace environment and their supervisor’s management style can directly affect personal productivity.

The perfect business analyst would appear at work, immediately put their head down, and come up for air eight hours later, having generated prodigious amounts of high quality output. The reality is that most people only spend a fraction of their work day actually doing productive work. It is hard to maintain the needed focus, and people find many creative, and often unconscious, ways to avoid it. There are techniques that individuals can apply to significantly reduce this wasted time. The business of bringing systems into existence is by its very nature creative. But most of the time, IT professionals tend to behave like plodders. We all get creative inspirations, but few of us recognize or act on them. Those who do so regularly are seen as creative geniuses.

A manager’s personal style has a direct impact on the productivity of their staff. While I think a supportive style works better that an aggressive one, there are plenty of the latter types around. Unfortunately, we are programmed to respond to fear and intimidation, so it can work. But when an aggressive manager’s behavior turns outright abusive, disaster will result. I once had to rescue a contract where the program manager had driven off every single first and second level manager and senior analyst on the contract within six months of taking control.

The ability of a project manager to effectively utilize the capabilities of the staff assigned to them can have a huge impact on the quantity, quality and timeliness of the work products of the project team as a whole. In some respects this is just Management 101. The key to real success is a combination of deep knowledge of what team members can do, combined with a great deal of flexibility in making and adjusting work assignments, including a willingness to jump outside of normal schedule when roadblocks are encountered. In addition, better results can be achieved if people are used in multiple roles.

My personal favorite is to use the same business analyst(s) who have elicited requirements to do system testing. Who else is better qualified to know whether a system has met its objectives? Quite a few immigrants come to America every year to work in the IT industry. These individuals tend to be hard workers, and can be very productive, but linguistic and cultural differences can be barriers to achieving that productivity. A supportive manager who is sensitive to these differences can work with these individuals to overcome these differences and realize their full potential.

John L. Dean is a seasoned IT professional with many years experience, including systems engineering, systems analysis, requirements analysis, systems architecture and design, programming, quality assurance, testing, IV&V, and system acquisition, equally split between technical and management. He has worked both the contractor and government sides of the fence, has been an employee of large (IBM, CSC, Booz-Allen, MITRE, ACS) as well as very small companies, and is currently an independent consultant. He has a Masters degree in Operations Research from Clemson University. You can reach him at [email protected].

Let the Celebration Begin!

Written by Cynthia Low on . Posted in Articles. 1 Comment on Let the Celebration Begin!

Thank-you! Thank-you! Thank-you!

We are officially one year old today! Without your involvement, it would have never happened. When we launched BA Times a year ago, we had two simple strategies to achieve our goal of serving the global Business Analysis community:

1. Provide current educational content and information
2. Create a forum for BAs to exchange ideas and information

Our internal goal was to have 2,000 subscribers by the end of the year! Well, I’m happy to say that we’ve successfully accomplished that goal and then some…

I’d like to recognize a few people who helped us along in our first year:

First 10 official BA Times Subscribers thanks for taking a chance on us:

  • Janette McGrath
  • Paul Thiara
  • Samuel McGrath
  • Paulina Corpuz
  • Kathy Vezina
  • Jenny Jones
  • Steve Willingham
  • Kate Edwards-Davis
  • Charmaine Jacskon
  • Sherri Marx
 First Content Contributors thanks for trusting us:

  • Kathleen (Kitty) Hass
  • Glenn R. Brûlé
  • Janette McGrath
  • Marcos Ferrer – our first Blogger
Internal team – without their support and dedication, there would be no BA Times:

  • Mike Morton
  • Sean Butt
  • Ollan Delany
  • Jimmy Manuel

BA Times has emerged as the industry’s leading BA portal and eNewsletter. We’ve grown to 5,726 subscribers worldwide! Here is the breakdown:

Subscribers Come from 86 Different Countries – Highest Subscriber % from:

  • United States – 50%
  • Canada – 20%
  • India – 8%
  • Australia – 5%
  • South Africa – 4%
  • United Kingdom – 1.5%
  • New Zealand – 1%

We’ve continued to refine the site and offerings over the past year and will not stop improving. Thanks to all your feedback and suggestions, we’re building more features!

Changes You’ll See Starting Today:

  • New site template with a cleaner look and drop down menus from the main menu
  • New event calendar, including the ability of subscribers to post events
  • Custom images for each subscriber and contributor

Here’s what’s coming this year:

  • Content Categories – we’ll be placing all our content into categories to help you better navigate both new and archived content
  • BA Times Sub-Communities – you’ll have the ability to create virtual private sub-communities within BA Times. Great for IIBA Chapter communication, dedicated country communication and networking, or any other reason you can think of
  • Elibrary – where users can submit book titles and comments for reference
  • Online Stats – where you can see stats of subscribers online and connect directly to build your professional network and opportunities

It’s been quite a year! We truly appreciate your support of BA Times and would love to see it continue to grow to support the needs of the Global BA Community. Our initial objectives have not wavered:

  • Provide current educational content and information
  • Create a forum for BAs to exchange ideas and information

We will continue to ask for feedback and improve the site based on your needs! I ask only one thing of each of you: If you like our content and online experience, then tell a friend in the industry about BA Times. Either forward them a current eNewsletter or our URL. We’ve grown over the past year solely by word of mouth and intend to do the same this year. All our resources go back into improving the website, not marketing for new subscribers. We are constantly striving to improve what we offer our current subscriber needs, not hunting for new subscribers. So spread the word!!

Thanks again for a great first year! We appreciate all of you!

Best Regards,

Adam R. Kahn
Publisher, Business Analyst Times
[email protected]

Struggling to Define Business Analysis and the Role of the BA.

Written by Cynthia Low on . Posted in Articles.

There is still a lot of debate in business analysis circles around what our role is, and what is offered by the various organizations, representing and supporting business analysts. Is the role all about requirements analysis? Are we just interested in IT and systems analysis or are our practitioners focused on the broader business and processes? Is certification of business analysts the answer?

I came across an interesting article forwarded to me by some information architecture friends. The article on the discipline and role of Information Architects (IAs) was written by Jesse James Garrett in 2002 and the issue of defining the roles of information architects that they were struggling with back then, are very familiar issues that we are now facing as BAs. If you enter the phrase “defining the damn thing” in Google you can still find remnants of that debate.

Garrett argued that there is a discipline known as information architecture as well as a role known as information architect and that they evolved hand in hand, but that the time had come for change. Similarly, just as there is the discipline of business analysis, there is the role of the business analyst.

If we define the discipline based on the role then we may potentially be too broad, as the role of a BA varies from organization to organization and encompasses BAs working as commercial, process, financial, technical and systems analysts. Organizations representing business analysts are looking to certification or accreditation as a way of defining the role, and bringing in some level of standardization in order to decrease ambiguity in the marketplace. Garrett, however, cautions that if we go down the track of defining the role we inevitably threaten someone’s sense of identity. If the BA’s role differs from the organization’s job description, then does it follow that they are not business analysts?

Alternatively, if we define the role based on the discipline, then whatever the field of business analysis is, those who are specialists in this field are business analysts. This definition however could, in practice, become too narrow. The potential to be “boxed in” may result in BAs having little influence or control over important aspects of projects, where BA competencies and capabilities are of great value and add strategic value to organization goals and objectives for process improvement.

As a BA I’m more often involved at a strategic level.  Rather than my involvement with projects ending with the delivery of requirements, I’m utilized throughout the project: I bridge the gap between the business and the technology team; review processes and operations; as well as investigating and advising on the project’s impact and dependencies on other systems and programs initiatives across the enterprise.

All this activity means my role is not easily defined. This is not because I’m trying to be all things to all people (the Project Manager, the Business Analyst and the Systems Architect) or take over another project team member’s role, its more a reflection of the discipline of analysis being increasingly seen as a core capability and that the frameworks and tools used for analysis can be drawn upon for expertise throughout the life of the project, and through all the programs across the enterprise.

In short, as a business analyst I do lots of things. Don’t put me in a box or label me and don’t predefine what I do … it limits the possibilities for my involvement to add value within projects, between projects, across programs and across the enterprise.

Garrett suggests that we seem to be at an impasse in the definition debate:

 “Any definition broad enough to encompass the role is too broad to foster useful discussion of the discipline; any definition narrow enough for the discipline is too narrow for the role….basing either definition on the other means one is going to be insufficient. Trying to do both at once isn’t working, producing a classic chicken-and-egg problem”.

This is where our business analysis “Community of Practice” can come together to shape the future of the profession. We should define the scope of what is business analysis as a discipline. Once we achieve this end, this will empower us to look at what the discipline offers in the way of frameworks and tools to interested practitioners, as the specialists in this field.

Ultimately, the definition, role, responsibility, and the future of BAs will be determined not by us, but by organizations that will base their decisions on their resourcing needs. It is therefore up to us as a Business Analysis Community to continue to promote what we do and how we do it, and share our knowledge, understanding and expertise within the community. By doing this as a community, we can go out to organizations and showcase the capabilities and competencies of business analysis. This will show the value of the discipline regardless of the role within the organization.  Instead of prescribing what a business analyst is or isn’t, let’s talk about our frameworks, our theories and what tools are out there to get the job done.

Maria Murphy is an experienced business manager and information and communications specialist. She has over 10 years senior management experience within the commercial environment, medical/pharmaceutical industry, not-for-profit organizations and government. She has experience with managing large federal government contracts and project management of large scale ICT business system reviews, development of requirements, systems planning and change management.

Maria is the Regional Lead for a Business Analysis at SMS Management and Technology and provides advice to her colleagues on developing requirements specifications for appropriate IT systems to support clients’ programs and initiatives. She can be reached at [email protected].