Skip to main content

Tag: Business Analysis

Be an IT Star: Practice Business Analysis Skills

Written by Kupe Kupersmith on . Posted in Articles.

Kupe_April26I came across an article written in 2008 on CIO.com and thought you would love to know the Four Secrets to Becoming an IT Star.  According to this article, being an excellent BA will help you on the path to stardom.  The author does not say that outright in the article, but it sure was my interpretation.  The fours secrets are:

Be good to your end user

The author of the article says if you want to get ahead don’t make people feel stupid.  You need to remember whether it is technical speak or discussing your business analysis process don’t try to sound smarter than your customers.  All that does it make them feel uncomfortable and not want to collaborate with you.  Don’t try to impress them with buzz words. Impress them with compassion and empathy.  It’s not about you; it’s about solving their problems. Always use language that is comfortable for your customer.

Go beyond the walls of IT and learn the business

This is so a business analysis activity.  The article talks about understanding business processes and observing the business community to know and see their pains.  As a business analyst, if you are not away from your desk talking with your business stakeholders and observing how they operate, you may want to consider another profession.   

Understand the organization’s structure and goals

As a BA you need to be focusing your efforts on the top priorities of the company.  When assigned to a project make sure you know where your project fits in with the overall goals of the organization.  During planning you should make sure you choose activities allowing you to spend the appropriate time based on the company’s priority of your project. In the article there was talk about creating value and knowing what the business views as high priority. As a business analyst this needs to be your primary mindset.  If an activity adds value to the goals of the company do it.  If it does not add value, don’t.

Build trust with your boss

In the article it is discussed that you have to be open and honest with your boss.  Share the good and bad news and don’t sugar coat issues.  The last thing a boss wants is to be blindsided with an issue which could he/she could have known about.  This is something I believe should go beyond just your boss.  In my last blog, It’s Time to Take the “Naked” Approach to Business Analysis, I touched on this concept.  You have to be open and tell the truth whether the news is good or bad.  This applies to your boss, your team, and definitely your business stakeholders. 

If you’ve read my earlier blogs you know I believe these are some of the qualities you need to separate yourself from the pack and be a desired business analyst.  I have also been saying for awhile now that the next generation of CIOs will be coming from the BA ranks. This article supports that conclusion especially since the article was written based on interviews with CIOs. So keep it up and be a star in your organization.

To soaring to the C-level,

Kupe

Don’t forget to leave your comments below.

It’s Time to Take the “Naked” Approach to Business Analysis

Written by Kupe Kupersmith on . Posted in Articles.

Kupe_April11Every now and then a book comes along that rocks my world.  Last week was one of those moments. I’m starting to sound like Oprah!  Although the book was not specifically written for business analysis professionals, it applies 100%.  The book, Getting Naked [1] written by Patrick Lencioni.  Most of my writing is about ways to become or stay a desired a BA.  If you want to take a leap forward in becoming desired read this book.  If I have not convinced you to buy the book yet keep reading. 

In Getting Naked Mr. Lencioni explains the approach, ‘naked consulting’, he and his team developed and practice in their management consulting firm.  The approach was designed to ensure client trust and loyalty.  In the book he explains the model around three fears that most of us live with.

  1. Fear of Losing the Business – Worrying about losing a client’s business may cause service providers and consultants to avoid the very things that ultimately engender trust and loyalty.
  2. Fear of Being Embarrassed – Rooted in pride, this fear can lead service providers to withhold their best ideas from clients.
  3. Fear of Feeling Inferior – To avoid feeling irrelevant or being overlooked, consultants try to achieve and preserve a high level of importance in clients’ minds.

By shedding these fears Mr. Lencioni has found that his clients are more trusting of him and his firm, more loyal, and best of all willing to recommend his company to peers at other companies. Here is a summary shared by the author on his website:

“We find that clients are more interested in candor, modesty and transparency than they are in confidence, authority and perfection.  That’s not to say that competence is irrelevant; clients need to know that we have the knowledge and experience to help them.  But once we’ve reached that level, the best way to differentiate ourselves from competition – not to mention help a client implement the ideas we’re recommending to them – is to be vulnerable with them.”

How does this apply to the business analysis professional?  In my post, No One Wants to Work with a Jerk, I discussed having the experience and knowledge of the technical aspects of our profession is parity.  You won’t separate yourself from the pack if you only focus on the technical aspect. It’s the softer side that differentiates you and your team.  For our profession this is what Mr. Lencioni is talking about when he says “That’s not to say that competence is irrelevant; clients need to know that we have the knowledge and experience to help them.  But once we’ve reached that level, the best way to differentiate ourselves from competition – not to mention help a client implement the ideas we’re recommending to them – is to be vulnerable with them.”

Whether you view yourself as a consultant or not, you are a consultant or a service provider.  Many BAs don’t want to admit they are consultants because there is a negative view of that title. This is due to many consultants’ fear of losing business, fear of being embarrassed, or fear of feeling inferior.  By defending against these fears most consultants come across arrogant and egotistical.  Their focus is on how smart they are and a lack of focus on the customer’s needs. 

There are many great principles in this book that we should all be implementing. For today, I want to make a point about fear of losing the business.  If you don’t work for a consulting firm equate this to fear of losing your job.  As part of this fear Mr. Lencioni talks about telling the kind truth. Difficult messages need to be delivered even if the receiving end does not want to hear it. As a BA you have to take the viewpoint of what is best for the company. It has been said by me and others that the value of business analysis shows itself when a project gets canceled or redirected.  BAs are in the perfect position to recognize when a project is off course and not aligned with the goals of the company.  If you see this happening you can’t sit back and let the project continue; even if the project sponsor or your boss really wants to implement the project.  You need to tell the kind truth and help the sponsor or boss see why the project needs to be canceled, delayed or redirected.  I have spoken with many BAs who are scared to raise these issues due to the potential of hurting their career at a company or potentially losing their job.  First, I agree with the author that “naked consultants understand that they have a responsibility for being a truth teller, even if this means they will be sacrificed.”  If you lose your job because of bringing up issues like this, do you really want to work there?  If enough bad projects continue most likely the company will go under or at least have some layoffs and reorganization efforts. Either way you can be impacted.

“Getting Naked” is a quick read jammed with great content.  This book will give you ideas on how to make sure your focus is always on doing what is good for your clients and help you become a desired BA.  As a BA community we need to continue to improve and the concepts in the books can definitely help if implemented.

How about we start Kupe’s online book club.  Once you read this book please come back and leave your thoughts on how you plan to implement the concepts.  If you have read the book, tell us what you think?  Have you implemented any strategies yet? 

To being “naked”,

Kupe

Don’t forget to leave your comments below.

1 Book:  Getting Naked: A Business Fable About Shedding The Three Fears That Sabotage Client Loyalty
Publisher: Jossey-Bass; 1 edition (February 2, 2010)
ISBN-13: 978-0787976392
Author: Patrick Lencioni

Are We There Yet?

Written by Zenobia Godschalk on . Posted in Articles. 1 Comment on Are We There Yet?

Zeena_Feature_March22_modifiedIn my previous blog (http://www.batimes.com/articles/requirements-development-101.html), I described requirements development (RD) and its activities. After reading the blog, some of my customers inquired “just how long does it take to do proper requirements development?” Honestly, there is no set time to this question. However, I can categorize some environmental factors that can extend the time required for proper requirements development. You should add time to your RD schedule in the following situations:

  • Skill level of the analyst and process maturity –
    • if the project has less experienced analysts;
    • if there are no standard RD activities or documentation in place;
    • if there is no reuse of the requirements;
    • if there are no peer reviews throughout the RD phase;
    • if you don’t store requirements in a single repository.
  • User involvement –
    • if there is none or very little user involvement or
    • if there are many types of users.
  • Stakeholders’ response time –
    • if the stakeholders are not co-located;
    • if there are languages or cultural barriers;
    • if key decision-makers with conflict resolution power are not identified.
  • Project size and complexity –
    • if you are building a new application versus rewriting a legacy application;
    • if you are re-engineering your processes AND building the application at the same time;
    • if you have external interfaces;
    • if the developers or testers are not knowledgeable in the application being defined.

I always tell my customers to use historical data when determining the RD effort and adjust their time estimate by addressing the above environmental factors. If you don’t have historical data, then it’s never too late to start collecting some metrics from your current RD efforts. Unless you are following a strict waterfall methodology, I wouldn’t create a onetime estimate from my entire set of requirements, but instead create estimates for each incremental phase. Also, I set the expectation that with each incremental phase, the estimates will change, but they will also be more accurate because you will know the health of your project better as you execute through its life cycle.

For example, Agile projects have numerous, very small RD phases. Agile teams do “just enough” requirements definition before proceeding to development and testing. This allows for the users and stakeholders to rapidly provide feedback to the analyst, which results in improving the requirements development efforts with each iteration. The length of time of an increment doesn’t matter as long as the stakeholders and users understand the requirements for that specific iteration. If they don’t, then you will repeat the rework efforts of the past iterations.

Whenever a customer asks me “Are We There Yet?”, it leads me to believe that they want to speed through the requirements development phase – just to say they did it. It has been shown that spending more time on requirements can accelerate software development by decreasing rework activities. We all know that requirements issues are one of the major causes for project pain.

The Standish Group asked their survey participants about the reasons that cause their projects to be” challenged”. Below are the percentages reported by their CHAOS Report, they define “challenged” as “the project is completed and operational, but over-budget, over the time estimate, and with fewer features and functions than initially specified”:

Project Challenged Factors % of Responses
1. Lack of User Input 12.8%
2. Incomplete Requirements & Specifications 12.3%
3. Changing Requirements & Specifications 11.8%
4. Lack of Executive Support 7.5%
5. Technology Incompetence 7.0%
6. Lack of Resources 6.4%
7. Unrealistic Expectations 5.9%
8. Unclear Objectives 5.3%
9. Unrealistic Time Frames 4.3%
10. New Technology 3.7%
Other 23.0%

This indicates that three of the biggest issues leading to project pain are due to poor requirements engineering. What this really means is that when the project was delivered, there was a difference between what the stakeholders and users needed or wanted, and what the developers built. Better software requirements can lessen this difference, which can provide numerous benefits to all the project members.

  • Project Managers – Better requirements enable organizations to effectively decide which projects to fund because better requirements show a more precise estimation of business return on investment.
  • Product Mangers – Once a project is selected, better requirements help in the assessment of effort and resources because the complexity of the requirements can be correlated to development and testing efforts.
  • Analysts – All features may not not be able to be delivered, so better requirements allow the team to prioritize the features more effectively. This will make certain that the project executes the most important functionality.
  • Design and development teams – Because requirements establish product design, better requirements facilitate the design and development team to more effectively select the right solution.
  • QA teams – Better requirements allow the prioritization of features thus enabling the testers to focus on developing the important test cases first.

As we know, it is more expensive to fix defects later in the software development cycle than during requirements development. Consequently, your company’s profits can be influenced and correlated to requirements issues. Therefore, it is crucial to invest in better requirements activities rather than solely worrying about how long it takes to do proper requirements development. This estimation will improve with time once you’ve established a good requirements practice.

Don’t forget to leave your comments below.

Zeena Kabir is a Sales Engineering Consultant for Blueprint Software, the leader in requirements definition and visualization software. Prior to Blueprint, Zeena has worked 20+ years in the IT field in the areas of requirements engineering, testing, and development. She holds a Bachelor of Science degree in Computer Science and a Master of Science degree in Software Engineering from the University of Maryland. She resides and works with many IT organizations in the Mid-Atlantic region.

IT Methodology – Offering Small and Mid-sized Businesses (SMB’s) Operational Performance and Impressive Bottom Line

Written by Cameron Watson on . Posted in Articles.

As world market conditions continue to evolve, so too have the pressures and expectations being placed on organizations.  In many cases, the difference between red and black ink can often be attributed to the operational effectiveness derived from the “IT Efficiencies” of the organization.

Since information technology became a part of the business mainstream, business stakeholders, IT practitioners and academia have debated the various and most effective organizational “IT Efficiency” solutions. Though opinions have differed, most concur that an “IT Methodology” is one of cornerstones any organization can leverage to increase its operational performance and bottom line. Many agree that an organization that utilizes an “IT Methodology” has a competitive advantage in its ability to deliver and support its products, business applications and day to day operations.

For the sake of context, “IT Methodology” can mean different things to different organizations and audiences. As a noun, “IT Methodology” can be viewed as the roadmap project managers and business analysts rely on to consistently deliver products and applications on time and within budget – examples include IBM’s Rational Unified Process, PMI’s Project Management, QAIassist’s Integrated Methodology, Prince2.  As a verb, “IT Methodology” can be viewed as the various modes of travel (practices and techniques) a project manager applies while using the roadmap to get to their destination (completed project) – examples include waterfall, agile, spiral, rapid application development RAD.

The benefits of an “IT Methodology” are:

Repeatable Organizational IT Process – An “IT Methodology” (noun) can be applied as an organizational process.  As a process, organizations are able to define, utilize and repeat a common approach used to develop and support their products and business applications. By utilizing an “IT Methodology” as a process, organizations are able to introduce corporate quality assurance (quality products and applications are produced when the process is followed) and organizational improvement (analyzing the metrics and measurements of how the process is being used).

Consistently Deliver Applications on Time & Budget – In being repeatable, an “IT Methodology” (noun) affords organizations reliability in how products and business applications are developed and supported. Project team members (stakeholders, business users and IT) are able to understand their roles and responsibilities, project plans can be defined and approved, and the necessary deliverables and artifacts needed to complete the project can be identified. Applying an “IT Methodology” establishes a degree of structure that project teams leverage (and re-use) to deliver their projects on time and on budget – the more often it is used, the more proficient the project team becomes at applying it – the more proficient they become the greater the savings in time and budget.

Optimize Communications (Stakeholder, Business Users, IT Project Teams) – An “IT Methodology” (noun) acts as the glue that keeps a project team together and working from the same page. This includes project stakeholders, business users and IT project teams. Project Managers are able to dedicate project resources to specific responsibilities and the creation of specific deliverables and artifacts as part of the project plan. Project team members have a clear understanding of their roles and responsibilities and procedures used to administer the project. Project Stakeholders will have a mechanism to quantify the status of the project team with regard to progress, risks and issues. 

Incorporate Organizational Governance – An “IT Methodology” (noun) provides senior management a tool that can provide predictability (schedule, costs, quality) on how the IT staff develop and maintain products and applications. This predictability affords senior management flexibility to budget and prioritize what applications are to be completed, when they can be completed and what resources will be available to deliver these products and applications. It also provides senior management an ability to re-adjust the priorities of the IT resources to reflect the business priorities.

Establish Resource Diversity – An “IT Methodology” (noun) provides organizations a basis for developing cross-functional expertise in both the business and the IT sides of the house.  As a resource learns more on how an “IT Methodology” is applied they can leverage that expertise to become effective in other areas of the business (i.e. an apprentice carpenter that has learned to use a hammer to build a dog house can rely and re-use that same knowledge when building a deck or a house). This offers flexibility in how resources are to be applied and offers staff an avenue to gain additional expertise and knowledge in other areas of the business.

Though the concept of increasing operational performance and bottom line through an “IT Methodology” may be obvious, there remains a huge gap in how various organizations are able to implement these solutions.  Large sized organizations have traditionally relied on large sized IT tool vendors and consultancies to acquire and implement complex and all-encompassing “IT Methodology” solutions – in the majority of cases they have created internal Project Management Offices (PMO’s) specifically dedicated to implementing and supporting these “IT Methodologies”. SMB’s have not always had the same financial flexibility nor the same need to acquire and implement these elaborate and all-encompassing “IT Methodology” solutions offered by the large sized IT tool vendors and consultants.

In today’s world, SMB’s are being squeezed from many directions and must rely on their ingenuity and nimbleness to navigate through these challenging realities. All too often the difference between an SMB keeping its doors open and making a profit is a direct result of its operational performance and “IT Efficiency” – on whether or not it utilizes an “IT Methodology”. Although benefits can be derived from an “IT Methodology”, SMB’s must assess the other side of the ledger in the Return on Investment (ROI) equation – implementation requires addition considerations.  They include:

Access to “IT Methodology” (noun) – Traditionally SMB’s have had limited options in acquiring an “IT Methodology”. Their only alternatives were (a) acquiring the complex all encompassing solutions offered by the large tool vendors and consultancies or (b) not using any one at all because the costs of acquiring these all-encompassing products and services are often too great.

Acquiring an “IT Methodology” (noun) – As more and more SMB’s are recognizing the competitive advantages of implementing an “IT Methodology” several vendors and consultancies are now delivering scalable products and services that afford SMB’s the products and services they require to improve their operational performance and bottom line.  Scalable “IT Methodologies” (i.e. project management, software development, software testing) can now be acquired at a minimal cost – a standard licensing fee is applied. Licensing fee applies to the initial acquisition and a minimal monthly support fee.

“IT Methodology” Implementation – Upon acquiring an “IT Methodology” SMB’s must go through the exercise of having it customized (scaled) to ensure it is optimized to contribute to both operational performance and the bottom line.  Though implementing an “IT Methodology” is unique to every organization, most SMB’s will incur costs associated with customizing the “IT Methodology” to their specific circumstances, training the staff on the applying the “IT Methodology” and coaching the staff through several  initial projects.

Ongoing “IT Methodology” Expertise – As an SMB becomes more proficient at applying their “IT Methodology” there may come instances and temporary circumstances where they will require additional “IT Methodology” expertise in delivering or supporting additional products and applications. In these cases it will be advantageous for them to acquire consulting resources familiar with the “IT Methodology” – these resources will be able to make an immediate contribution to the project team and an impact on the delivery of the product or application.

As global competition continues to drive business and technology, organizations armed with an “IT Methodology” increase their operational performance and their ability to consistently deliver higher quality products and services to their clients. The result – more satisfied clients and an increase in bottom line.

 Don’t forget to leave your comments below.

Cameron Watson is the President of QAIassist. QAIassist helps small and mid-sized organizations (SMB’s) increase their operational performance and bottom line through IT efficiency. QAIassist’s Integrated Methodology incorporates the disciplines and deliverables SMB’s leverage to consistently deliver quality applications on time and within budget. Visit QAIassist’s website-www.qaiassist.com

Business Analysis: Is it a Bottleneck in Your Project?

Written by Ross Wilson on . Posted in Articles.

How often is a project manager, architect or developer waiting on the Business Analyst to complete a requirements document, finish a model, or finalise a process. As all business analysts (BA’s) know it takes time to identify and talk with all stakeholders, elicit requirements, analyse them, then document and review them. And as good business analysts we all want them perfect and very detailed with no ambiguity.  But how do you produce such well defined, clear, concise, non ambiguous and detailed requirements in projects where expectations are greater, deadlines are getting shorter and budgets are tighter.  As the time given for gathering and documenting requirements decreases, so too does the detail and quality of the documented requirements.  We all know how long creating those amazing models takes.

I have worked in a number of organizations and on many projects, and it is common in project teams to have only one person acting as the business analysis on requirements, while there is  a team of developers making the code changes or developing the software from scratch. After all – often only one requirements document may be being produced so why put more than one person on it.

Getting good quality detailed requirements is critical to a project and a good business analyst is required to produce them. But why not put two or three or maybe even more business analysts on a project or function. When was the last time you worked on a project where business analysts outnumbered developers? So why not have more people working on one of the most critical phases of a project? Some of the advantages are shared knowledge, collaboration, peer reviews, a greater range of ideas and possible solutions, and reduced timeline if more resources are available.  And any cons can be overcome with good project and document management techniques and tools, even egos can be overcome.  But often a company’s business analyst’s resource is stretched and putting more than one on a project or function is just not possible.

So if we can’t apply more people to the problem of reducing the requirements timeline then how else can we do it?  Well we see more and more talk about agile development methods where business representatives talk directly to the developers cutting out much of the need for BA’s.  This can work in the right situation and in the right environment, but many companies and projects have found agile causes more problems with overruns and quality issues when not fully embraced and understood.

I have seen a project work where multiple BA resources worked on the requirements and specialised in particular areas. The requirements were not completely detailed up front but the business vision was, and high level requirements were documented to a level that allowed estimation to be performed.  Then as each iterative development phase started on each business area the BA responsible would verbally present his or her concept to the development team in detail, with mock screen shots or story boards, models of the process, and associated business rules. Allowing the developers and testers to see the complete picture as well as the detail is important and allowing them to ask questions and seek clarification on issues instantly speeds up the process of transferring information.  If anything does change then an efficient and quick change management process is very important.

The process of documenting requirements is often a lengthy one that produces many large documents. I know I have written many large requirements documents full of detailed requirements, Use Cases and diagrams in my time.  On the positive more time gives our requirements more detail and clarity, unfortunately this can often lead to more time spent on changes and change control.

So is a large requirements document or many Use Case documents the best way or best practice.  Well the answer is it depends. It depends on the organization and their development process and rules, and if the whole team is located together. Some organizations still have a very rigid waterfall development framework, strict financial models, that requires formal reviews by a large number of stakeholders before the next phase progresses. They rely on large detailed requirements documents and accurate cost estimates. The costs are a large part of this process and it is easy to understand all these controls in a large organisation, but it does mean the requirements process of capturing, analysing, documenting and reviewing requirements takes a long time. We see more and more press about agile development methods and many companies want to take advantage of these without understanding how their whole development framework needs to change.

So what we want is a way of speeding up the requirements process without losing any of the detail or the communication to stakeholders that allows them to confirm the requirement and therefore deliverables are correct.

Vision documents are excellent at capturing the stakeholders’ vision and needs of what is to be delivered, and Use Cases and User Stories are effective ways of communicating how someone will interact with a system and how it will respond, as well as capturing the all important alternate and exception conditions.  The quality of service requirements are also important as they give us the parameters by which the system must operate under.  Other supplementary specification documents capture report and interface requirements.  So it is important we capture all of these things and convey them for approval to the stakeholders and developers.  It is how we do this that can change and speed up the process.

I know if I have to stand up in a room and present requirements or Use Cases to a group of people I really want to know and understand what I am talking about so I can not only present it well I can also answer questions on them.  So if I have to present requirements to stakeholders or developers and a view of the proposed system then I also want to know I have captured all the detail and understand it well. People also seem more open to asking questions when there is someone there to answer them.  You also have the advantage of seeing if people are confused or lost when you’re explaining something that allows you to rephrase or simplify what you’re saying.

I have found that by talking to stakeholders and developers you are able to convey more information and understanding than from just a written document, in a much shorter time frame. But it is important that everyone hears the same information and gets the same picture.  So conveying requirements verbally to developers is seen as answer to speed up the development process as we see in agile development, especially if you are always available for developers to confirm details with.  As with anything there are risks but there are ways to mitigate them.

So in my experience a middle ground is important.  We need to capture the business’s vision in a document because it will be referenced a lot and it is an important we capture it in detail and clarity.

With requirements and Use Cases capturing a high level view is important but much of the detail can be conveyed verbally. We need to capture enough detail to ensure we have identified everything and have enough detail to perform a preliminary estimate. And detailed use cases are important for critical or high risk parts of an application.  And working closely with developers, architects, and testers is important.  After all it’s about the solution and not just the requirements.

Don’t forget to leave your comments below.

Ross Wilson is a Principal Consultant with Equinox Limited in Auckland, New Zealand, specialising in requirements management. He has been working in IT for 27 years and has a wealth of varied project experience in a number of different industries. For the last 14 years, he has focused on business analysis, project management, and team leadership. Ross can be contacted at [email protected]