Skip to main content

Tag: Project Management

A Blog of a Different Color – BAPM

This month we continue our series of collectible diagrams with Business Analysis Planning and Monitoring. Last month we covered the “Initiation of BA Activities.” You can get a legend to help read these diagrams by grabbing last month’s diagrams, if you haven’t already.

Here we go!


Click on the images for an enhanced view!

Trigger Evaluation of Business Need and Initial BA Activities BAPM 1st Step to Task 2.1
BAPM 1st Step to Task 2.2 IMAGE_4_TINY
IMAGE_5_TINY IMAGE_6_TINY
IMAGE_7_TINY IMAGE_8_TINY
IMAGE_9_TINY IMAGE_10_TINY

Don’t forget to leave your comments below.

 

Business Analysis: Is it a Bottleneck in Your Project?

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]

Requirements Development 101

Many organizations that I work with understand that better requirements engineering practices would alleviate many pains in their current software development lifecycle (SDLC). But some of these organizations don’t know how to improve their practices because, I believe, they don’t fully appreciate the world of requirements engineering. So I am writing this article to describe, at a high level, the components that make up requirements engineering. Once the components are understood, then organizations can see what is missing or what needs to be modified in their current environment to arrive at a better practice.

First, let’s define the term requirements. There are millions of web sites that can give you this definition, so I went with Wikipedia (http://en.wikipedia.org/wiki/Requirement). It states that “a requirement is a singular documented need of what a particular product or service should be or perform”. This, to me, means there are many, many kinds of information that fit into this thing called “requirements”. To simplify the matter, let’s start breaking down these kinds of information into categories, or different “types” of requirements. At a minimum, an organization should collect these types:

  • Business Requirements -describes the values this project will provide the organization once it is finished. Some organizations have a vision and scope document, while others just roll it into the generic Business Requirements Document (BRD).
  • User and Functional Requirements, and Business Rules – these describe what the software needs to do and what the development teams need to build. Some organizations have a Use Case or Functional Requirements Specification (FRS) document, while others have it in the one BRD.
  • System and Data Requirements, Quality Attributes, External Interfaces, and Constraints – these types are just a handful of non-functional requirement types that you can collect. Some organizations have a Software Requirements Specification (SRS), while others have it in that BRD, which seems to be looking pretty big right now.

Now that we know what to collect, we need to understand how to collect them. Requirements engineering is broken down into two activities: requirements development (RD) and requirements management (RM). I find most organizations do requirements management well. This is to say, they can manage changes to a set of baselined requirements that have been identified to a specific release. What I find is most organizations have a hard time setting a standard practice around requirements development. I will spend the rest of the article describing this activity. RD is broken down into the following sub-activities:

  • Elicitation – this involves interviewing the stakeholders and determining their needs. This is not writing down everything they say. Stakeholders will not know everything they need the first time you interview them. What they do know, may not fit into the scope of the project or may not be in agreement with the next stakeholder you interview, or may even be wrong. Therefore, elicitation is an iterative and inventive activity. Think of yourself as a detective that asks the questions that gets the stakeholders to think of missing or new requirements that are within the scope of the project. A good way to get the stakeholders to open up is to ask all the “What if …” questions. Another very useful technique to use is to ask “Why?” These questions can reveal missing or unspoken requirements or offer additional details to enhance the understanding of a requirement. Creating these types of dialog is an effective way to increase the completeness and quality of the requirements versus just writing down everything that they say.
  • Analysis – this involves developing detailed requirements from elicitation. These detailed requirements don’t need to be just textual in nature. They can be of different forms, such as business process diagrams, data models, use cases, and prototypes. By gaining greater detail, you will also discover missing requirements. Analysis offers an effective way to recursively refine the understanding of the initial elicited requirements. This is also where you will settle priorities of requirements between stakeholders and arbitrate between conflicting requirements. Because the analyst is the communication hub with all the stakeholders, it is a good idea to identify key decision-makers that will have the final yea or nay power when conflicts arise. This will become even more important when you communicate the requirements downstream to the testers and developers, therefore quick and efficient conflict resolution process is important.
  • Specification – this involves documenting the various types of requirements, which can be textual or graphical. It is usually a good idea to have a few documentation standards for vision and scope document, FRS, SRS, BRD, etc. Many analyst web sites have examples of these types of document standards.
  • Validation – this involves making sure that the requirements are correct and will meet the stakeholders’ needs. One good way to validate requirements is to have the stakeholders develop user acceptance criteria. These criteria specify the primary tasks the software will allow the users to perform and the common errors that the software will handle. Comparing the requirements against the user acceptance criteria will establish if the requirements are correct. On a side note, they also provide starting points for testing scenarios for the quality assurance team.

I would like to point out that you don’t need to develop all the requirements for the entire project at once. Requirements development is an iterative process, so trying to develop detailed requirements all at once can lead to analysis paralysis. During elicitation, you will identify the high priority or first built features. Start with analysis and specification of these requirements and do validation with a quick informal review. Then move to the next set of elicited requirements for analysis and specification, all the while correcting the previous set of requirements of missing or misunderstood requirements that are discovered along the way. By infusing quick review cycles between analysis and specification, you will filter out errors and increase the completeness and quality of the requirements with each cycle. Having multiple cycles will refine the requirements to a level of detail that can be efficiently communicated to the stakeholders, testers, and developers. At the end of the day, a project will never have a set of perfect requirements, but it will have a good enough set of requirements to proceed to development and testing. Since we can never produce a perfect set, we want to adopt practices that result in fewer requirement defects, especially the ones that have high impact and severity. We can weed out these nasty defects before they are injected into the SDLC. This can decrease the amount of development rework, which results in reduced product cost and quicker time to market.

On a final note, to further increase efficiencies in your requirement development activities, you should input all of the requirements in a single repository. It lets you capture elicited requirements and you can you can easily access them for usage as the basis for initial development of detailed use cases, UI mockups, data models and business process diagrams during analysis. Also a requirements repository allows you to trace any requirement to any other requirement. Since it is a repository, you can trace across all these elements to see all the dependencies and evaluate the impact of changes.

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.

Bad Business Analysts, Project Managers, and Relationships

Larsons_Main_Feb8The “Bad” BA or PM. Is there such a thing, I wondered, when our editor asked for blogs on this subject? In giving it some thought it seemed to me that there may not be any bad business analysts (BAs) or project managers (PMs), but there certainly are some bad BA and PM practices. I’ve compiled a list of some of my favorites. As an aside, some of the worst BA/PM behavior occurs when the relationship between these two critical project roles struggles. In this blog I address bad BAs, bad PMs, and bad BA/PM relationships.

Bad Business Analysts

The “B-A-A-H-d BA”. That’s right. The BA who acts like a sheep. I’ve met many of them over the years. These are the BAs who lack courage. They do not see themselves as influencers, but rather as order-takers. They seem to forget that they are high-level management consultants who “recommend solutions that enable the organization to reach its goals.” (BABOK® Guide Version 2.0, Introduction, Section 1.2).

These b-a-a-a-h-d BAs:

  • Answer “you want it, you got it,” when given a solution. It may not occur to these BAs that when given a solution, it is necessary to find out what business problem is being solved or what business opportunity is being seized. These BAs may not know what questions to ask, or they might be afraid to ask the right questions. Either way, they tend to plow ahead with the requirements of the proposed solution without understanding the real business need. Not too long ago a client told me, “When the sponsor says they want something, who am I to question it?”
  • Bleat “Baaaah as they follow the pack. I have seen knowledgeable and experienced BAs go along with the business subject matter experts (SMEs) even when they are aware of business and technical impacts and dependencies. As above, they might not be comfortable asking questions or providing their insights and advice.

The “BAD idea BA” who thinks that all ideas presented are bad. We call these BAs initial rejecters. For these BAs, no idea has merit until it has been thoroughly analyzed. Do ideas need to be analyzed? Of course! Do risks need to be addressed? You betcha! But initial rejecters can be viewed as complainers who push back on all new ideas. Effective BAs, on the other hand, understand the importance of a positive, helpful, and non-combative attitude.

The “B-A-H-d Humbug BA” These are the BAs who listen politely to the business SMEs and then turn around and ignore them. I have actually heard one of them exclaim, “They don’t know what they want, so I’ll give them what I think is best for them.” Another equally well-intentioned BA once told me “I have a lot of experience and know what’s best for them. “

Bad Project Managers

When our editor asked for characteristics of a bad PM, I said to myself, “That’ll be easy. As a PM, I’ve made every mistake in the book.” Below is just a sampling of the mistakes I made as a BAD PM.

  1. Telling the business SMES “I’m sorry you can’t have that feature or function. It’s out of scope.”
  2. Asking a business SME at the beginning of a requirements workshop, “What are you doing here?”
  3. Not nailing down the project objectives during Initiating.
  4. Because of a tight deadline, telling the developers that they needed to focus on project tasks rather than answering questions of and being mentors to members of other development teams.
  5. Hoping that a team conflict would go away and thus taking too long to resolve it.
  6. Not recognizing that we were in analysis paralysis until the sponsor blew up in total frustration.
  7. Letting methodology get in the way of providing good customer service.
  8. Omitting lessons learned and/or not spending the time to review lessons learned from past projects.
  9. Not communicating the team’s accomplishments regularly to the powers that be so they could get the recognition they deserved.
  10. Not understanding the importance of team dynamics in project success.

Bad Business Analyst and Project Manager Relationships

There are some project professionals who when acting alone as a BA or as a PM are “good,” but get them together and the project becomes a battlefield. These are the PMs and BAs who can’t seem to work well together.  Here are some examples of “bad” BA/PM relationships. Most of these examples stem from each role not understanding the other, from not defining roles and responsibilities, and from not having an understanding of the work involved or the empathy for the difficulties of the other role.

  1. Both the PM and BA think it’s their job to define the business need and project objectives.
  2. PMs who think that the BA plays a subordinate role on the project. They don’t understand that for the project to succeed, it’s best for the relationship to be peer-to-peer.
  3. PMs who think that the BA’s job is nothing more than elicitation and documentation.
  4. PMs who think that it is their job to plan the business analysis work.
  5. PMs who micromanage the business analysis effort.
  6. BAs that confuse business analysis with project management.
  7. BAs who keep the PM out of the communication loop.
  8. BAs who promise new and changed features without discussing the project impacts with the PM.
  9. BAs that become aware of business risks and don’t notify the PM.

These are just a sampling of bad BAs, bad PMs, and bad relationships.

Don’t forget to leave your comments below.

4 Steps to Improve the Relationship with Your Project Manager

Kupe_Blog_Dec21It seems like every year there is still talk about the project manager role and the business analysis role in the same sentence.  It started years ago with the questions “do business analysts grow up to be project managers?” Then, why a project needs both a Project Manager and a Business Analyst.  Now the PMBOK includes requirements activities which sparked the IIBA and PMI to write a joint paper about the overlap in the roles.  With the PM/BA topic still hot my colleague at B2T Training, Barbara Carkenord, and I put a slight twist on the subject.  Although many teams use one person as a PM and BA there are still a large number of teams that have separated the roles.  In both circumstances there are pros and challenges.  One of the challenges when there is a PM and BA is the potential for unclear responsibilities. We came up with an approach for a PM and BA partnership meeting. This meeting is done early in the initiation phase of a project to open the lines of communication and give the BA and PM greater chance for success.   Because the PM and BA interact with the same stakeholders it is very important for the PM and BA to be very clear on what roles each will play during a project.

Assess Yourself

To build a strong partnership you first need to know yourself.  What are your strengths and what tasks do you enjoy doing the most? What are your personal preferences? We always work harder and better on work that we enjoy.  There are aspects of each role that you may enjoy. For me I enjoy all aspects of project scoping.  I make it known to my PM that I can help or lead that activity for the project.  Prior to the meeting with your PM, have a clear picture of what you want to do and how you can best contribute to the project.

The Planning Meeting

When assigned to a project make a point to set up a planning meeting with your PM.  Here is a 4 step process you can follow to help guide the meeting.  

1. Get to know each other

If this is the first time you worked together or if it has been some time since your last project together discuss individual strengths and weaknesses. Learn s much as you can about your partner.  Do they work better in the morning or afternoon? Do they prefer working mostly as a team or are there certain tasks they would rather do on their own then review later.  Here are some specific items to discuss.

  1. Learn about each other’s work history (jobs, roles, projects).
  2. Share your passions, strengths, and areas of challenges.
  3. Talk about your feelings about the partnership. Discuss how you like to work with others.
  4. Tell your partner what tasks (both PM and BA work) you enjoy and excel at.

The key here is to be as open as possible. 

2. Discuss project characteristics

Use the project charter or similar document as your guide.  Discuss the project specifically. Share knowledge of stakeholders to think through the best ways to communicate during the project.  Make sure you both are clear on the project objectives and the key stakeholders. If you have a different understanding or the objectives are not clear, make sure this is resolved before the project gets too far along. You’ll also want to talk about the approach (plan driven or change driven) to be used for the project.

3. Discuss the requirements approach

Depending on the knowledge and background of the PM you are working with make sure you have agreement on your requirements approach.  Make sure you and your PM have the same understanding of the requirement types that need to be elicited, analyzed and communicated. Come to an agreement about what documentation may be required for the project.   

For elicitation discuss the techniques you may use.  If your stakeholders are at different locations, talk about the possibility of some face to face sessions.  Have the conversation about providing a travel budget.

4. How to best work together

With all this information about each other and the project it is time to decide who will do what on the project. I said this in so many words in a previous blog, My First Agile Project, but it is worth repeating again.  Titles and predefined tasks for that title matter less to me than getting the best person to accomplish a task.  Just because you are a BA does not mean you only do tasks outlined in the BABOK.

When you are first assigned to a project schedule a meeting with your Project Manager. Review the project charter before the meeting and develop a list of questions/suggestions for how the two of you can work together. If possible, this type of meeting should be had with all team members. 

Do you have meetings like this?  Please share your story in the comments.

Always working on relationships,

Kupe

Don’t forget to leave your comments below.