Skip to main content

Small Projects Drive Me Crazy!

Written by Kupe Kupersmith on . Posted in Articles.

OK, it is not small projects that drive me crazy. It is what I see project teams doing because a project is classified as a “small” project. Teams get the feeling that there is no need for a BA, no need to follow a process, and/or no need to plan. All of these thoughts just because the project has been labeled as a small project! That’s what drives me bonkers. And what happens on most of these projects? Teams struggle, things are missed, and at the end of this small project, teams scramble to finish up. Of course, no project retrospective is done because; well…it was a small project.

My philosophy is that every project is different, and the team needs to take the steps that add value to the project. This does not mean planning is not important or following a process is not important. It means plan as much as necessary and take the steps in the processes that are needed. You need to analyze each project and determine what makes sense. I know many companies that try to classify projects by size, and then decide if a BA is needed, what techniques to use, how much to document, etc. I have heard people say a small project should have less than 50 pages in a requirements package. So if there are 60 do we no longer classify the project as small? Why try to keep a BA to documenting “x” number of pages? The number of pages should reflect what is needed for that project. The problem with this approach is that projects do not easily fall into buckets. There are too many factors that you need to consider in order to determine what techniques to use, and so on. The type of project, the people on the project, and internal company processes are all high-level factors that need to be considered. Putting projects in buckets opens the team up for failure and focuses the team’s attention on rules in a process. Their attention should be on the customer and the goals of the project.

Teams come up with a process for small projects that are different than large projects because teams try sticking to a prescribed process for every project. Trying to implement every step in a process is overkill for some projects. Coming up with another prescribed process does not solve the problem. In my Going Rogue blog post I think some of you had the impression I do not believe in having a process, or not needing a process as you get more experience. That is not the case. What is true; I don’t believe in a strict prescribed process for everyone and every project. I do believe in a process. It just needs to be fluid and ever-evolving. It has been proven by smarter people than me that having a repeatable process is the key to improvement. A process gives you an anchor to track areas of success and areas for improvement. So, I do believe a process is absolutely necessary.

The only step in a process I can say for sure is needed for every project is planning. For every project the step that must always happen and be taken upfront for a BA is plan the approach for each project. From that plan a determination will be made as to what techniques to use, how much to document, etc. For the techniques chosen, the BA should use the rules or guidelines outlined in the overall process. For example, if use cases are planned to be written for the project, the BA should use the template provided. A BA does not need to complete every step in a process, but if they do perform a step they need to be consistent with the other BAs in the organization.

Projects are not an exact science, so don’t try to place a prescribed process for each and every project. Try to understand the variables of the project, the people, the internal processes, and then plan your approach. I approach projects like I approach my kids. They are each very different, so I treat them in the manner that is best for them. I do not cheer for my oldest daughter at sporting events because she shuts down and stops playing. My son loves when I scream like a raging lunatic at games because he thinks it’s funny. I say it motivates him and he does not want to admit it yet! My youngest daughter, well, I have not figured her out yet!

Happy New Year everyone. I am looking forward to another year of great discussions on the profession we all love!

Kupe

Don’t forget to leave your comments below

Jonathan “Kupe” Kupersmith is Director of Client Solutions, B2T Training and has over 12 years of business analysis experience. He has served as the lead Business Analyst and Project Manager on projects in various industries. He serves as a mentor for business analysis professionals and is a Certified Business Analysis Professional (CBAP) through the IIBA and is BA Certified through B2T Training. Kupe is a connector and has a goal in life to meet everyone! Contact Kupe at [email protected]

How Can BAs Be More Strategic in an Agile Environment?

Written by Maria Horrigan on . Posted in Articles. 1 Comment on How Can BAs Be More Strategic in an Agile Environment?

As a business analyst working in the business area, I am finding myself more involved in the enterprise strategy arena and working across many projects. More and more, these projects follow an agile methodology. I’ve been traveling a bit lately and needed some reading material for my trip so I thought I’d revisit Sun Tzu’s The Art of War.

The Art of War focuses on strategy and planning and in an agile environment, there is much insight and wisdom BAs can gain from this sixth century BC Chinese General. Here are just six of his ideas that I think most capture the essence of agile as a philosophy and the core business analysis competencies I have been using on my projects, to help me adapt to an agile framework.

1. Discipline and Control of the Game – “…marshalling of the army in its proper subdivisions, the graduations of rank among the officers, and the control of military expenditure”¹. When I am presenting on Agile, one of the criticism I get from the audience is that Agile lacks rigor and discipline and is a more laissez-faire approach. I suggest to them that even though Agile fosters innovation and creativity, the project’s success is not the result of luck or a fortuitous accident, but rather the result of consistent planning and effort. On my projects, everybody’s role is clear and each knows what we need to do to get to the next stage or complete the next stream of work. My BA approach on Agile projects is iterative, as a team we learn and adapt as we go, but that doesn’t mean there is absence of planning and coordination.

2. Be Flexible and Run with Opportunities – “Avail yourself of any helpful circumstances over and beyond the ordinary rules. According as circumstances are favorable, one should modify one’s plans”¹. Sun Tzu was known as a master of controlling the game through leadership and discipline, but in this passage he is referring specifically to this need to remain flexible in changing conditions and be prepared to capitalize and follow up on an opportunity. This is the essence of Agile. When we commence projects, it is not possible to know all we can about the environment, the business and user needs. Requirements will change and evolve as we progress through the project and learn more about the situation and context. As a BA we must have a focus on continuous learnings and applying these learnings to the next stream or iteration is the key.

3. Act Fast to Avoid Fatigue – “Though we have heard of stupid haste in war, cleverness has never been associated with long delays”². Protracted campaigns can damage morale and resources and Master Sun suggests taking swift action to avoid the pitfall of expense and exhaustion. A number of years ago, I worked on a project that had already been going for two years when I joined. People were clearly tired and weary from the ‘battle” and project costs were blowing out. We regrouped and adopted an Agile approach. We had stand-up meetings every day within our team but we only engaged users when we had some progress in our work to show as these users and business groups were fatigued after two previous years of consultation with nothing to show for it. Within six months we had a working prototype from end to end, and a strong and committed BA and design team that rallied behind the Change Manager leading the project. It was important that we had “quick wins” early to keep the momentum towards our goals and manage the change process from “as is” to the “to be” state. Having a change manager to help facilitate and progress requirements through the various governance members was a big advantage.

4. Ensure Your Goals and Objectives are Realistic – “…by commanding the army to advance or to retreat, being ignorant of the fact that it cannot obey”². I think this really speaks to the heart of the user-centered design focus of many of my Agile BA projects. Master Sun warns that mistakes will be made if orders are issued from the safety of a far off court that doesn’t have experience of the combat situation. The business context and “big picture” strategy need to be mindful of the day-to-day operations. The people who are on the ground and know the capabilities of the current team and resources are the best source of knowledge for work shopping the business drivers, processes and gaps in order to uncover the business and user needs for your project. This is where BAs have a key strength and knowledge base. For example, once I have captured these needs, I always talk to the technical team to see if what the users want is realistic and possible (within out budget and capability). If there are sound limitations to what is possible, then I go back to the business and users and discuss alternate ways to achieve the same goal. Users then give me insight as to whether this alternate idea is practical. This iterative approach is critical to solving some of the more complex issues on the projects.

5. Employ the Right People for the Job – “… by employing the officers without discrimination, through ignorance of the military principle of adaptation of circumstances. This shakes the confidence of the soldiers”³. Finding the right people for the job is imperative. In Agile projects it is important to look at the essence of what the project is about and what problem it is aimed to solve and then decide what skills are needed and what patterns to apply. From this planning we then look at building the team. Of course you do not always have the luxury of being able to pick your team for projects, but if you set up an Agile team and draw from skilled resources across the organization, this is more likely to aid the success of your project. Reverse engineer the position; don’t just look at who you have and see if they will fit, find out what you need and then seek people with these skills and abilities. BAs bring many skills to the project and in Agile I have found that my skills of analysis are used beyond traditional requirements gathering. I have been involved in design, information architecture and business strategy workshops.

6. Adapt as Strategic Rigidity is Dangerous – “Water shapes its course according to the nature of the ground over which it flows; the soldier works out his victory in relation to the foe that he is facing”4. This emphasizes the need for fluidity and that to be successful, you must adapt. The business environment is dynamic and constantly changing and adaptation is key. As Charles Darwin stated “It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change”. As BAs in an Agile environment, you need to understand your user (primary, secondary and tertiary) and ensure that your processes and systems are developed with their needs in mind. When building user personas, start with a “skinny” view of this user and flesh it out as you find out more about their needs. Likewise, your business requirements will be “skinny” at the commencement of the project and will be elucidated more as the project progresses and each stream build upon the knowledge of what is working and what is not.

As an enterprise BA I am looking not just at my immediate project, but also how this work fits into the rest of the organization. Sun Tzu stresses the need to plan, find the right people, and give them resources and authority to execute those orders, choose a strategy and vary your tactics according to the situation. In looking at the essence of your projects, take the time to plan what you need in terms of skills, patterns to apply, things to do and things to produce and be flexible in your approach to adapt these to the project learnings as you progress, or the business needs or circumstances change.

References:

SunTzu’s Art of War, A 52 Brilliant ideas interpretation by Karen McCredie, 2008

¹The Art of War, Sun Tzu. translated from the Chinese by Lionel Giles, MA (1910), Chapter 1 – Laying Plans

²The Art of War, Sun Tzu. translated from the Chinese by Lionel Giles, MA (1910), Chapter 2 -Waging War

³The Art of War, Sun Tzu. translated from the Chinese by Lionel Giles, MA (1910), Chapter 3 – Attack by Strategem

4 The Art of War, Sun Tzu. translated from the Chinese by Lionel Giles, MA (1910), Chapter 6 – Weak points and Strong

Don’t forget to leave your comments below

Maria Horrigan is an experienced business manager, IT strategic planner and information and communications specialist. She has over 10 years senior management experience within the pharmaceutical industry, not-for-profit and Government. As a principal consultant, Maria is an experienced information architect, senior business analyst and IT strategic analyst and provides advice on developing system requirements with a focus on information architecture and user-centred design, to ensure appropriate IT systems are intuitive and usable. She is a senior practitioner and a well-known Australian speaker on communication, user-centred design, and business analysis. She has experience managing large federal government contracts and project management of large scale business system implementation, systems planning, and analysis and change management. She has a reputation for innovation, managing change, driving strategy implementation and successfully delivering programs. Maria is a Board member and Vice President of Women in Information and Communication (WIC).

The Sadness of the Silo’d BA

Written by Kupe Kupersmith on . Posted in Articles.

Many organizations need to shift how they staff their internal BA resources. These organizations primarily staff one BA to a project. The BAs are out on an island working through the joys and challenges of a BA’s life. On smaller initiatives this is very appropriate, similar to having someone play the PM/BA role on smaller initiatives. For larger initiatives, (multiple stakeholders, larger business areas, etc.) BAs should be paired on projects.

The concept of pairing is discussed and debated in the programmer world, so I thought I would get that debate going in the BA space! I talk to people all the time about the need to come together as a community and support each other, especially when their organization structure has them out on islands. Coming together provides the opportunity to help each other and share stories of success and lessons learned. That is a great first start for learning and growing from each other. Now it is time to make the next step so organizations get the best from their BAs. Here are three key factors why BA pairing is critical.

Skill Set Development

The range of skills required by a business analyst is very wide. Even the best analysts may not have all the skills necessary for every situation. For the purposes of this discussion let’s distill the skills down to four key areas. The BA needs to elicit the business needs, analyze what they elicit, document what is necessary, and communicate what they elicited to ensure they understood the true need, and give the solution team what they need to build the right solution.

How many organizations have business analysts that can do all of these things at a high level, on every project? I think it would be safe to say, zero. So why do these companies staff one BA to every project? There is a huge risk in assigning less than qualified people to projects on their own. It is critical to evaluate the BA staff and identify everyone’s strengths and areas for improvement. Begin to pair BAs on projects to utilize the strength of each BA.

The pairing also becomes built-in training. By working closely with another BA you learn by being part of a real-life example. This is also a great way to help each BA try out new techniques with the help of a mentor.

Two Heads are Better than One

My current assignment has me analyzing business processes for a large business area for four sister companies. The goal is to determine the feasibility of implementing an enterprise technical solution to support all companies. I initially started off this endeavor as the only analyst on the team. I realized quickly that I needed another head to bounce ideas off of and validate my understanding of all the information I was trying to analyze. By pairing in this situation, key points were not missed and healthy debates allowed us to provide clear benefits and cautions for moving forward with an enterprise-wide technical solution. You can not deny that two view points provide a better chance for success than one.

I know many organizations do a great job implementing peer reviews. That only helps resolve a piece of the puzzle. The one doing the peer review does not have enough knowledge of the business area to help with the analysis. They review the end product after analysis was completed.

Increased Knowledge Sharing

The more people that have a deep understanding of a business area reduces the risk of that knowledge walking out the door. The down turn of the economy has slowed down the number of retirees and the amount of attrition due to people switching jobs. Once the economy begins to rebound, both retirement and attrition will start back up. This is the time to pair those BAs and keep some consistent knowledge within the team.

Many customers find it frustrating when the BA gets moved around and new BAs are assigned to each project. They feel they have dedicated a lot of time to getting an analyst up to speed on their business and then have to start over. Pairing helps resolve this by having multiple people with knowledge of the business. New BAs can be brought up to speed without having to take a lot of the business customer’s time.

This is a shift in how many organizations operate. Give it a try; I think everyone will be pleased with the results!

Happy Holidays everyone,

Kupe

Don’t forget to leave your comments below

Jonathan “Kupe” Kupersmith is Director of Client Solutions, B2T Training and has over 12 years of business analysis experience. He has served as the lead Business Analyst and Project Manager on projects in various industries. He serves as a mentor for business analysis professionals and is a Certified Business Analysis Professional (CBAP) through the IIBA and is BA Certified through B2T Training. Kupe is a connector and has a goal in life to meet everyone! Contact Kupe at [email protected]

The State of Requirements Management

Written by John Simpson on . Posted in Articles.

Goodbye 2009, Hello 2010!

For many organizations, 2009 simply can’t end fast enough. The brutal economy made for a tough year, there’s no denying that. However, taking a moment to reflect on things from a business analyst’s point of view, I believe there are a few bright spots to celebrate. Consider them the signs of hope for a better 2010. In this article, I want to highlight three trends we first saw emerge from The State of Requirements Management Report we published back in June 2008 on the challenges, trends and solutions happening in software product development. In that report we surveyed 200 organizations and explored topics such as:

  • What are the biggest challenges in innovation that companies face?
  • Is the Agile process over-hyped?
  • How does collaboration apply to requirements management?
  • What frustrates people more – scope creep, unrealistic expectations or lack of testing?
  • Which genre of music is most popular? OK, that one we threw in just for fun.

I never anticipated the kind of response that report would get, with over 18,000 downloads of it since we first published it, but in hindsight I think it struck a chord with people, especially those in the business analyst community, shedding light on some of the challenges we all deal with day in, day out. You can read the full report and compare the results to what you experienced this year. I would be curious to hear your thoughts and experiences. http://www.jamasoftware.com/media/documents/State_of_Requirements_Management_2008_Jama.pdf

As I look back on 2009, the three positive trends I saw emerge which will carry over into 2010 include:

1. Greater Respect and Appreciation for the Business Analyst Role

Understanding what the customers need and documenting all the requirements isn’t easy. In fact, these were the top challenges based on feedback we saw within The State of Requirements Management Report at 65% each.

stateofreq1

As it becomes more apparent to executives and senior management that requirements are the building blocks of innovation, the respect for the people whose job it is to manage requirements increases. Can you say “Christmas bonus”? And, I’m not talking fruit cake; give the BAs you love something good this year!

In all seriousness, this heightened appreciation for BAs is also reflective in its being an area of job growth, despite high unemployment rates in other sectors. Essentially, if you have strong business analyst and product management skills, you are in high demand. Feel good about that for a moment, now put down the eggnog and get back to work. You’re only as good as your latest specification, right?

2. Greater Accountability for the Requirements Shared by the Entire Team

Collaboration has been a hot trend in product development for a few years now. But, what does that really mean in terms of results? One of the lesser known benefits of better collaboration is that over time you see an increase in accountability across the entire team for getting the requirements right and building the products to spec. That’s a good thing for everyone. How often before did all the responsibility fall just on the shoulders of the business analyst or product manager to define the set of features and write gorgeous requirements that would be magically understood and implemented flawlessly by all?

stateofreq2

Truly collaborative teams embody this shared accountability which raises the bar for everyone involved, whether it’s your job to listen to the customer and capture the requirements or interpret the detailed requirements downstream to code and ensure the functionality is right. When everyone contributes to the development of the requirements, the success rates increase dramatically.

If your team doesn’t embody this characteristic now, you might want to make it a priority in 2010, or hope for a miracle bag of requirements pixie dust from Santa. I think that’s high on the wish list right after the Wii and Twilight stuff.

3. Agile is More of a Mindset than a Development Process.

Man, there was a ton of attention given to Agile again this year. Agile conferences. Agile books. Agile processes du jour. I think I’ve contracted “Agileitis”, the rapidly, contagious disease that can be spread from the “pigs” to the “chickens” in a Scrum daily stand-up meeting… I know there’s a bad Swine flu / Bird flu whopper of a joke in there somewhere.

The key point is, Agile isn’t just a flavor of development process. It’s a core philosophy – a cultural mindset of embracing change, inviting the voice of the customer into your process throughout, and designing workable software that is continuously improving over time. Call them releases, iterations, sprints, milestones – whatever you want. The labels are less important than the outcome of the products you produce. The evolution I saw emerge in 2009, and will continue in 2010, is the concept of a “hybrid” approach where mature companies merge disciplined requirements management practices for proper planning and requirements documentation, with the freedom for developers and testers to adopt more agile, lightweight methods to build and test new releases. It’s the best of both worlds.

stateofreq3

I’ve seen many companies be successful with a hybrid process, and one of the reasons it’s more prevalent now is that the tools available today are designed to flex to support whatever process or processes work for your team.

Big picture – the goals are the same – build great products faster, cheaper and with higher quality. My recommended New Year’s Resolution: Adopt whatever mix of processes, people and tools you need to achieve your goals, demand and accept nothing less, and you’ll have a great 2010.

Looking ahead to January – Share Your Voice.

In January, I’ll be conducting the 2010 State of Requirements Management Survey and would love your participation. That way, we can establish an annual benchmark study for our industry on what’s real and what’s hype, and see what others are doing to be more successful managing requirements. So look for that after the holidays.

On a personal note, from my family to yours – I’d like to wish everyone and their families – happy holidays and best wishes for a prosperous new year! See you in 2010.

Don’t forget to leave your comments below

John Simpson is director of customer outreach and marketing at Jama Software. John represents the voice of the customer in Jama’s product strategy and communications. He has over 12 years experience working at software technology companies including Microsoft, WebTrends and Omniture. In his spare time, he chases his three kids around and raises awareness for cancer research in his local community, Portland, OR. You can reach John at http://www.jamasoftware.com or follow him on Twitter at http://www.twitter.com/jamasoftware.

Agile BAs… Don’t Go in without TOOLS!

Written by Robert Galen on . Posted in Articles. 1 Comment on Agile BAs… Don’t Go in without TOOLS!

In my last post I discussed the role of BA as it relates to working within agile teams and tried to explain what you can and should do as part of your team. One of the comments I received related to the role of User Interface Designer in agile. I had implied a complementary role in the post and the reader was looking for a bit more information. I thought it was a really good question and it’s led to this follow-up post…

Applying user interface design in agile methods is one of the leading challenges right now within the agile community. Since it’s an early-on activity, as is any design activity, the notion of sprinting till your done-continuously delivering working software iteratively doesn’t seem to engender much in the way of design.

Thus the challenge…

What design practice has done is encourage the agile folks to slightly reconsider their models. For example, within the design space, it is often quite reasonable to do design work within an iteration, that will only be ‘used’ in subsequent iterations-say the next one or two. This sort of look-ahead from a design perspective is required as the team can rarely implement the work within the same iteration where the design was explored and defined.

The trick is to not look-ahead too far. If you do, you fall into the waterfall trap of designing everything in advance, before you’ve actually gotten a few lines of code to work. (Something we agilists describe as BDUF – or Big Design Up Front and a common anti-pattern of agile development).

So this creates a need to oscillate or balance activities within your agile teams between some look-ahead tasks such as architecture, analysis, and design and then transitioning to coding and testing. I think the best agile teams ‘get’ this balancing act early on and understand that they have to work on both sides of the equation.

There are a couple of tools within the agile arsenal that foster look-ahead. I’m going to speak to a few. While they’re often ignored by the more purist-focused agile methodologists and teams, they are indeed a quite viable tool-set for looking before you leap into iterations.

  • Chartering. In the same spirit as traditional project chartering, agile chartering focuses on developing the why behind the project. Usually it targets the business case for the project including: target customers, vision for the project, ROI information, budget details, high level scope targets, team and capabilities information, and definitions for success – usually including a schedule or date target. The charter should serve to energize the team by sharing the why it matters behind the project or effort.
  • Research Spike – User Story. At times you really don’t know enough to write a solid user story. Usually the gap is in technical or design experience and what you really need is a little time to “play around” with things to gain a better clue. The output of a research spike isn’t working code. Instead it’s knowledge – usually in the form of architectural design details and a refined set of user stories destined for implementation in a later iteration. As a rule of thumb, I usually see 20% or so of stories in my backlogs that warrant a spike to gain more clarity.
  • Iteration #0 or Sprint #0. Quite often agile teams simply dive into their work, iterating before they have a clue to where they’re going. For some projects, this seems to work and the team figures out their direction along the way. For many others, this is a disaster. Jim Highsmith coined Iteration 0 as a term in his Agile Project Management book. It’s defined as a first/early set of iterations that are focused more towards getting ready to begin building a product than on the actual construction. A wide variety of work can be encompassed in a Sprint #0 including, architectural definition, requirement analysis and backlog preparation, design work, setting up office space and building the team, training, project chartering, group planning activities, etc. The caution is not to allow your Iteration/Sprint #0 to extend too long.
  • Blitz Planning. Alistair Cockburn defines Blitz Planning as part of his Crystal agile methodology. Crystal hasn’t achieved much popularity, so you probably haven’t heard much about it. However, there are techniques within Crystal that are quite powerful and this is one of them. In Blitz Planning you engage the entire team and key stakeholders in defining the overall plan of attack for the project. This includes developing the overall feature set, work tasks, dependencies, identifying key milestones, and such. At the end of a day or more of collaborative planning, you end up with a detailed, end-to-end mapping of the work. This includes when and how you’ll be doing analysis and design in order to effectively drive your agile iterations during construction.
  • Story Mapping. Jeff Patton is one of the champions of this technique and is actively refining it. What often happens in agile product backlogs is that the individual stories often obscure the big picture and overall direction a product is taking. Story mapping strives to connect individual stories into the themes and feature interactions that your real customers will be using. Typically, it’s a low-fidelity technique where story 3×5 cards on a way are elaborated and refined from the customer workflow and user interaction points of view. It often identifies gaps and helps to prioritize what should be implemented in what order.

For those of you who thought that agile did little in setting the stage in advance of the work, I hope this post and the tools open your eyes to a different perspective. While the agile methods do take a lean, iterative view towards software construction, many projects need some initial vision setting. I also think these techniques can be mapped, to good effect, to the more mainstream methodologies. Happy exploring!

Don’t forget to leave your comments below

Robert ‘Bob’ Galen is the President and Principal Consultant of RGCG, L.L.C. Bob has held director, manager and contributor level positions in both software development and quality assurance organizations. He has over 25 years of experience working across a wide variety of software technology and product domains. Bob can be reached at [email protected].