Author: Kupe Kupersmith

4 Steps to Improve the Relationship with Your Project Manager

Written by Kupe Kupersmith on December 21, 2010. Posted in Articles.

It 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.

Learn about each other’s work history (jobs, roles, projects).
Share your passions, strengths, and areas of challenges.
Talk about your feelings about the partnership. Discuss how you like to work with others.
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.

Is Your Business Analysis Process Like Buying a Car?

Written by Kupe Kupersmith on December 7, 2010. Posted in Articles. 2 Comments on Is Your Business Analysis Process Like Buying a Car?

This past weekend my wife and I bought a new car. I was replacing my 14 year old Ford Explorer and had 3 cars in my sights. I went to 3 dealerships to test drive those cars. What a nightmare! I thought the car buying experience was going to be better than 14 years ago. I actually think the process is worse.

With all the online tools available and my network of friends I did all the research. I knew which cars I liked, what the dealers pay for the cars and what people in my area have been paying for them. The first step I took was to submit my information on the dealership’s website, get a price quote and set up an appointment to test drive the car. For each dealership I received an automated email stating I was a preferred customer and when I arrived at the dealership I would speak directly to a manager. The manager would work with me to test drive the car and settle on a price. I was lead to believe I could expect to be in the dealership for 30 minutes to an hour. With my preferred customer number the dealership had all my information. What a great way to buy a car, right! Absolutely…if it actually went down like that.

When I arrived at the dealership, I was quickly moved to work with a salesperson who started to ask me what car I was interested in. He broke out a form and began asking me for my name, phone, address, email etc. I am a calm and patient person, but this set me off. This person knew nothing about me and it would take 30 minutes to explain what I already shared with the dealership online. I left the dealership letting them know I was not planning on buying a car from them. Could you believe 3 days later I received an email from the internet dept. of that dealership asking me if I was still interested in a car. Aah!!!! I was reminded why I don’t buy cars often.

Is your business analysis process like buying a car? I hope it is not close. Your process needs to be customer focused. I spoke with someone a few weeks ago and her organization was still in a “throw it over the fence” mode. That fence was so high and thick that she never received a question from the developer and was not even sure what the implemented solution looked like until it was in production. When she told me, the look on my face had to be saying, “Are you kidding me?” I assume her business stakeholders felt like me when buying a car. They shared information with the BA and then when the developer had questions they were probably asked the same types of questions..

At another company they did not throw it over the fence, but they still used a poor version of waterfall. The developers and QA team were not brought in at the beginning of the project. The BA would review requirements with the tech lead and QA lead that would then estimate the build and test portion of the project. If the high level estimate was approved developers and QA analysts were assigned. You think they had questions? Even if the questions were not asked directly to the business stakeholder, their time and money was being spent on a lot of knowledge transfer.

This extra time and some unnecessary back and forth with your business stakeholders does not help promote the value of Business Analysis. As the BA you need to raise your hand and demand some change if your project lifecycle is not customer focused. Your role is to help implement solutions to improve the business area you support. Always make sure your process is geared towards that goal.

Always be easy to deal with,

Kupe

My First Agile Project

Written by Kupe Kupersmith on November 23, 2010. Posted in Articles. 2 Comments on My First Agile Project

I was assigned to a team with individuals with skills including programming, business analysis, project management, quality assurance, database administration and subject matter expertise. The scope of our project was well understood by all. It was very clear what value this technical solution was going to add to the business. Quickly the team assembled and we outlined the tasks needed to meet the goals of the initiative. Together as a team we assigned tasks based on the expertise of each individual regardless of title. Individuals stepped up and took responsibility for their tasks and were bought-in to the plan because it was their plan, it was our plan.

The feature list was laid out and prioritized. Then we grouped features together and prioritized each group based on business and technical input. There were three overall groupings which outlined how we would develop the system. Each grouping would produce a workable solution that could be released to production to be determined by the business.

Our team was a cohesive unit and worked very well together to overcome the many challenges that come with every project. Team meetings were happening daily to ensure progress was being made and to highlight potential obstacles. Everyone was on board that we needed to get issues on the table as soon as possible so they could be addressed quickly to minimize risk. After each feature grouping we regrouped and discussed how we could improve and made sure our next grouping still had the correct priority. In the end the team delivered a high quality solution that met the goals of the initiative by delivering the full solution in three chunks. We had a very satisfied customer and a project team that did not want to stop working together.

The year…1997. Project methodology used…a modified Rational Unified Process (RUP), which is considered a traditional approach. Was this my first agile project? Technically, no. The agile manifesto was not created until 2001. When describing my project you’ll notice I did not use common Agile terms like Scrum, user stories, product backlog, daily stand-ups or co-located teams. At the time of this project these terms were not defined as they are today.

Obviously our team definitely did not use an agile methodology, but we were definitely using principles that support the Agile Manifesto. Here are some of the key principles our team lived by:

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

“Working software is the primary measure of progress.”

“The best architectures, requirements, and designs emerge from self-organizing teams.”

“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

My feeling is that the popularity of Agile development methodologies is keeping the focus off of exactly what the Agile Manifesto is trying to address. The manifesto was developed to focus us on building better software to add value to the businesses we support. Instead of focusing on that, the focus is Agile vs. traditional methodologies.

This week I attended the Project Summit/Business Analyst World conference in Chicago. Agile was a topic discussed and it is clear “Wagile” and Scrumfall” methodologies are alive and well. These are combinations of traditional and agile methodologies. These are project methodologies that look at the skills of the team members and the culture of the organization to put in place a process that will help teams build better software.

The moral of my story is to keep your focus on building better teams to add maximum value to the business. Many of you are probably already focusing on the principles that support the Agile Manifesto and have been for years. Learn about new techniques that are being used and see how you can use them to improve. Don’t focus on whether you are using an Agile methodology or a traditional methodology. Do you think your business stakeholders care? Most likely not. They want the solutions faster, better, and cheaper to help them run the business.

To finding your methodology,

Kupe

Business Analysts Need to Learn from Developers

Written by Kupe Kupersmith on November 9, 2010. Posted in Articles.

There was an article in the November issue of InformationWeek that made me think of this title. Developers just get it when it comes to keeping up with new technology and finding ways to stay current. Yeah, some developers try to use their new toys on our projects even if it is not really needed, but they also do it on their own time.

Years before the BA community had online communities like this one, BA Times, developers have been sharing knowledge and experiences online. I remember being very impressed when a developer I worked with was struggling with a way to code a feature we needed. He told me to come back the next day and he’d have an answer. He asked a few simple questions on an online community and poof, potential solutions came rolling in. I’m glad to see us engaging around the world on the various communities. I realize our answers are never quite as exact as a solution for a developer, but at least we give each other options to consider.

When mentoring BAs either looking for a job or trying to excel in the one they’re in I often hear things like “I don’t have time for that”, or “I can’t do that at my company”. Lame excuses if I ever heard them. This is where BAs are falling short and a place we can learn from our developers. The article I read was talking about developers working on open source software projects where only 9% of contributors are paid. If you are not paid to do something you are volunteering. Why do developers volunteer their time? The article discussed the main reasons are they find it fun to solve problems and it is a sense of accomplishment. The other reason that stood out to me was contributing was a way to master a new technology. These developers don’t say they have no time or sit idle while they work on necessary projects at work. They make time so new technology does not pass them by. You need to do this too. If you want to grow, if you want new opportunities, do not pass up volunteering…make the time.

Success story time! A friend of mine is a director of a BA group. She had an acquaintance that had zero BA experience, but wanted to move into the field. With no experience she was getting nowhere fast. My friend was working most weekends and offered up the option for this person to come in on the weekends and help her for free. In return she gains valuable experience working with an expert in the field. For 3 or 4 months (I can’t remember exactly) every Saturday this no experience BA worked as a BA. My friend was so impressed with her passion an aptitude for BA work that when an opening came up, she hired her. She has since excelled in her role and has had the opportunity to get some formal training.

I try to find ways to use my BA skills in every opportunity. I recently signed up to lead a math team at my kids’ school to help a number of students prepare for a math tournament coming up in January. Since I was new to this role, I was not sure how the system worked (like the various communication methods I needed to use to contact parents and their children, when to work out details with the teachers, how to work with the principal, the process for scheduling math team practices, etc). So, I used a few BA techniques do document the process and the business rules. If you ever had to work with PTA (Parent Teacher Association) you know there are rules. Many of you volunteer already in varying organizations. Think how you can use a BA technique in your current volunteer work. It is a great place to try out these techniques without being judged. This is a great opportunity to try out a technique you want to add to you repertoire but have not had the opportunity at work. More than likely people will be impressed. The downside to that is you’ll keep getting calls to volunteer!

We can learn a lot from developers about how they learn and stay current. Stop reading this and go grab lunch or coffee with your favorite developer and see how they are staying current.

If you have a story related to learning methods to stay fresh please share them in the comments.

Never stop improving,

Kupe

Dont Forget to Leave Your Comments Below….

Business Analysis Love Fest at BBC

Written by Kupe Kupersmith on October 25, 2010. Posted in Articles.

I just returned home from the Building Business Capability conference in Alexandria, Virginia. It was a co-located conference with the IIBA, the business rules community, and the business process community. A common belief among attendees was that the combination of these three communities was a marriage made in heaven. At the end of the conference Ron Ross stated, in so many words, that we have to stop focusing on gurus of software development and start focusing on building business capability. As you can imagine, all three camps are big believers in understanding what an organization needs to achieve its strategic goals. Software may enable that, but it is not always the main driver. I had the feeling we were at a Barak Obama campaign speech and the entire crowd was going to scream back, “Yes we can”.

There were three main points in time at the conference where I felt we were at a political rally. The first was at a presentation given by Barbara Carkenord and Elizabeth Larson. They spoke about a paper written in conjunction with the IIBA and PMI to highlight the overlap of the PMBOK and the BABOK. The tone of the presentation was to show how the PM and BA can work together, not against each other. The 100 plus in the crowd were ready to march behind Barbara and Elizabeth. I could sense that almost everyone wanted to shout “Amen” at one point.

Next was a presentation on Enterprise Business Analysis given by Jason Questor. He introduced us to the work being done by the IIBA on the subject. Most of the attendees there were in alignment that our business analysis skills allow us opportunities in the strategy arena within organizations. These skills give us the ability to go beyond project work. Jason told a story about Kathleen Barret, president and CEO of the IIBA, letting an audience know that she believes business analysts will grow up to be CEOs. Talk about a rallying cry!

The third was at the closing panel, where a number of the audience felt the three communities should band together. The IIBA viewed as the broader picture with specialties in business process and business rules. Many attendees were thrilled to have learned more about each community and couldn’t wait until next year’s conference. I could tell many did not want to leave and go back to reality.

I was among those that thought how great it was to all come together, and I think a similar conference should happen next year and beyond. We need time to come together and learn from each other. Now that we have all hugged and said our goodbyes the real work begins. It was easy for all us who believe in business analysis, business rules, and business process to agree.

But, why are there still so many individuals and companies not focusing on these areas? If we want to make large wholesale changes in our organizations, each of us needs to perform better every day. We need to continue to show our value to make the changes we all believe in. Many of us at the conference walked away with ideas on how to improve and make that change. Mark Jenkins, KPMG, said you don’t always have to ask for permission, just do something…anything. Gladys Lam, Business Rules Solutions, said “just do it”. She wanted to make sure we went out and tried some of the things learned at the conference. She pushed us to not worry about being wrong and that we will improve iteratively.

What are you going to do? Don’t stick with the status quo. I am hoping a year from now there are more stories of how our community has helped built better business capabilities.

Please use this as a forum to discuss stories of how you are showing your value. We can all learn from each other.

Kupe

Don’t forget to leave your comments below