Do You Promise to Tell the Truth, the Whole Truth, and Nothing but the Truth

I can see the court room setting - the Business Analyst is on trial because the Business Client isn't happy with the software they just received. At first the Business told Development, "You didn't write the code correctly; the software doesn't do what we want." To which Development quickly said, "Our code is exactly to the requirements specification; it's not our fault." The Business Client then confronts the Business Analyst and says, "Show me the specification." To which the Business Analyst says, "Gladly, that's what I've been trying to do all along."

But here is where the problem occurs. In most organizations the requirements specification isn't "the truth, the whole truth, and nothing but the truth," instead it's a portion of truth in the Word document, and another portion of truth in the Visio diagrams, and another portion of truth in the prototype, and another portion in the spreadsheet. It is a series of disconnected pieces of information that may get bound together in a single document but the sources are separate and distinct from one another and often not in sync. As such, what ends up being bound together to appear as a "single version of truth" is really a bowl of spaghetti that's down-right impossible for the Business Client to digest.

Back to our crime scene - the Business Analyst reprints the 300 page specification and once again plops it on the desk of the Business Client. The Business Analyst then proclaims, "Had you read it from cover to cover and given me the feedback I needed early in the process, your software would be fine." Although this sounds like a good defense, it really isn't. It's flawed for two reasons: 1) it's extremely difficult for the human mind to digest a large amount of information, in a short and pressured timeframe. 2) It's even more difficult to piece together the many parts and pieces in order to truly see and understand the story being told. Yet this is what we ask the Business Client to do with the simple request - "just review my document".

The Business Client replies, "Oh yea, I remember that document, I did scan it, quickly, once, and it seemed okay. I tried to read it but there was so much in it and I couldn't really connect everything together in my mind's eye so I just trusted that you knew what I meant and signed it." The BusinessAnalyst snaps back, "But what about all those review sessions we had, in the conference rooms, where we walked through the document? The Business Client thinks for a moment, "Wait, that does sound familiar, but we had the same problem in the conference room as we did on our own. Even with the Business Analyst walking us through the document it was really hard to connect the dots. The Business Analyst would tell us to hold our finger on page 5 and flip to page 10 to see the business rule for this requirement, then flip to page 20 to see the screen that's related to it, then look at appendix "A" for the workflow diagram. You didn't really expect us to comprehend all that did you?"

Finally, the verdict is given - innocent!!

That's right, the Business Analyst is innocent of the crime because it was determined that they were doing the best that they could do with the sticks and stones they had been given to work with. It was determined that the Business Client provided the best feedback they could, given the time and pressures they were under, and that ultimately the blame fell on the shoulders of the mechanism, or medium, being used to communicate, not the author or reviewer of the story. As a result of this case, the Business Client declared a document free zone, instead of a penalty, and the Business Analysts were provided with tools that allowed them to not only author the many elements of the story in one central location, but review and validate the story in a contextually rich and visual manner that brought high praise, and great feedback, from the Business Client.

Unfortunately the "courtroom trial" portion of this scenario happens on a regular basis in most IT shops. The good news is, with today's technology it is possible to change the medium from big thick documents full of disparate parts and pieces, to visually oriented simulations, that walk through the story in a quick and simple way, so the Business Client can wrap their head around the story and provide the feedback so badly needed early in the process.

Read more about the requirements problem
Read about the most popular requirements workbench

 

10 Signs that you’re really “Wagile”

Yes, Wagile. For years now I have been going around as a certified agile Scrum Master thinking I was being humorous by introducing the term "Wagile" to those customers who thought they were agile but had fallen into a variation of agile that is best described by Wikipidia...

"Wagile software development is a group of software development methodologies that result from slipping from agile back into waterfall, doing a lot of short waterfalls and thinking it is agile, Waterfall model masquerading as Agile software development, etc."

OK, so I didn't introduce the term, but it is out there in abundance. Wagile usually comes about because a team or IT group is attempting to migrate to an agile methodology but they are either not given the autonomy to do so, the resources to perform in an agile manner or, worse still, they are bound by the old world of delivering huge Business Requirement Documents (BRD's) to stake-holders and are bogged down waiting for that elusive approval.

Don't get me wrong - I am not saying that I believe in the myth that Agile Methodology = Poor or non-existent requirements. The fact is, requirements are a critical part of running an agile development process, but one just takes a different approach when developing them. User Stories replace high level business requirements and the requirements being defined in one sprint will drive design and coding in a subsequent sprint. The net effect is that all these disciplines are active in every sprint of the lifecycle, but the relative emphasis changes depending on what stage you're at in the project. For example, Requirements tasks are being performed in all sprints, but they are emphasized more in the earlier sprints.

 

Compare this to the Wagile implementation where the team realistically is still performing a Waterfall methodology, just in a shorter timeframe. A lot of projects don't start out as Agile, they are in fact Waterfall and due to unrealistic deadlines and potential failure, deliverables are demanded in a shorter timeframe in order show progress. Teams simply have the same SDLC but are forced to deliver something short incremenets - e.g. 3 weeks or so duration. In this approach, requirements are usually being developed by the BA weeks ahead of a sprint starting. For example requirements for sprint 10 are being written while the coding and testing for sprint 7 is still being done. So how does this fit into the Agile Manifesto? Well, it really does not. The Agile Manifesto states "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage". This simply can't be achieved if the BA's are not fully engaged in the current sprint but are instead focused on 2 or 3 sprints into the future.

So in the spirit of Jeff Foxworthy and "You might be a Redneck if", let's consider "You might be Wagile and not Agile if:"

1. Your Scrum team consists of 20 people
2. Your sprints have "Phases" such as Requirements, Design, Implementation, Verification and maintenance.
3. You have a Project Manager and he manages you via MS Project and a Gant Chart.
4. You are assigned work and asked for daily status reports instead of letting the team learn how to manage its own work.
5. You never push back, "This is what the product owner wants in this sprint, so we have to get it done".
6. Velocity is simply the speed you achieve when you are late for work.
7. Your daily stand-ups (if you have them) consist if Chickens, Pigs, Lions, Tigers and Bears...Oh my!
8. You are still required to produce a large BRD to communicate requirements rather than "Just Enough" to get the point across. Ideally this is managed in a tool with traceability and simulation to help in the communication process.
9. You are pulled off your current sprint to work on that "other project" you used to be on.
10. It is 1am and you have a new release being implemented and the whole team is not involved.

 

Resources:
Authoring Requirements in an Agile World
Blueprint Solution: Blueprint for Agile Development

Houston We Have a (requirements) Problem

It's one thing to see the latest unemployment statistics on the nightly news but quite another to sit down for a coffee with your brother-in-law who just lost his job. Hearing weather reports of continued freezing temperatures in the south-eastern US is certainly of interest, but it doesn't hit home until you see the segment on the tropical fish-farmer whose family business was all but wiped out in just a few days. Statistics are necessary and useful for analysis, but to really appreciate their meaning - what they translate into ‘on the ground' - you need a few tangible examples.

If you're in the software industry - and I presume you are if you're reading this blog post - then you're well aware of software failure statistics. Seeing these statistics over and over you can get somewhat numb and the numbers become nothing more than, well, numbers. To help remember what these statistics really mean here are some lists of real software failures & issues.
While reading through these remember the findings of a 2006 report¹ that found "accurately capturing system requirements is the major factor in the failure of 90% of large software projects,".

To get you started, here's one with a video showing the result of this requirements error: 

Company: SAAB
System: JAS 39 Gripen. An advanced figher jet that requires computer control for stable flight.
What Happened: Instability during sixth test flight causes pilot to lose control and crash. Pilot fortunately walks away. Investigation revealed crash was due to a requirements error with the flight control system software. "the flight control system was doing what was specified but not what was required".
Complete Story Video

 
.. and a few more from SD Times:

"An early version of the Airbus crashed because the pilot could not wrest control away from the computer and restore the airplane to a safe altitude. The software developers apparently knew more about flying an airplane than the pilot."

"A laser-guided missile that depends on a forward ground crew that focuses the laser on a target will go to the coordinates of the laser beam. During the combat operations, the battery on the laser unit begins to fade. No problem. It is designed for a hot-swap capability. The software, however, was not designed for hot-swap and, without notifying the ground crew, resets the coordinates to origin after completing the hot-swap."

When the U.S. Federal Bureau of Investigation completed its Virtual Case File system in 2005, "Everyone looked and said, 'This is not something that we want,' " after seeing that it was incomplete and error prone. Consequently, the FBI had to answer to the U.S. Congress, which scrapped the project in January 2005. The government also failed to assess the cost of those additional requirements and the project cost soared to over US$100 million.

 

More real-life software failures & issues:
Software Horror Stories
Why Software Fails
History's Worst Software Bugs
Top Ten Corporate Information Technology Failures
Twenty Famous Software Disasters
ZDNet UK's list of top 10 IT Failures

 

 

 

 

1 - Davis, C.J.; Fuller, R.M; Tremblay, M.C.; Berndt, D. J. (2006) "Communication Challenges in Requirements Elicitation and the Use of the Repertory Grid Technique" Journal of Computer Information Systems. Vol.46, 5; p. 78.

Back to the Future: Reverse Engineering Requirements

Many organizations today have systems that have no or very little documentation. Users and customers have relied on these legacy systems to provide a reliable means to work on vital information. And as the business changes, more of these systems are being asked to be leveraged in ways that were not designed when first implemented. Reverse engineering requirements can dramatically improve an organization's ability to maintain, upgrade, and integrate to its legacy production systems. But the time and cost to do a total system documentation tend to balance the potential benefits. Instead, an incremental reverse engineering approach has the advantages of a quicker return on investment, reduced risk, and more flexibility. Hence, you need to go back to document these systems to move current organizations into the future.

There are two basic approaches to reverse engineering requirements:

Total System Documentation

To fully document the entire system (data files, back-end processes, user interfaces, new platform, etc.) and then validate the requirements can be very expensive and time consuming. And the problem space gets even larger for decentralized systems. But this approach becomes necessary when "the code quality of the original system is so poor that it can't be reused or leveraged", as stated in Blueprint's Application Modernization webinar. Hence, the entire system needs to be documented so that it can be redeveloped. Although an expensive option, redevelopment has the advantage of using modern tools, platforms, languages, and methods. If you need to go down this path, then be aware of a pitfall. Managing requirements of both the existing legacy system and its continual changes is extremely difficult and feasible only if the system is small. Some functional changes cannot wait until the old system has been documented. Thus, modifications to the legacy system must be continually updated in the documentation. This requires significantly more resources (time, money, and personnel). If the legacy system is too large or too dynamic, the organization may not be able to afford the expense of parallel requirements definition.

Incremental Reverse Engineering Requirements

A key decision when planning incremental reverse engineering requirements is how to decompose the legacy system to its components. Most likely, the decomposition decisions will be based on a mixture of the below strategies. There are different ways to decompose a legacy system:

Physical Site
If you have decentralized systems, then this approach works well. For example, all systems at a given site will be documented first. Or documenting a re-hosted system will occur before any other requirements definition activity.

Functional or Business Need
Reverse engineer requirements of software components that are mission-critical to the organization. Once you have those critical components documented, and then identify all the components that contribute to it. And work your way out via a spider web from sub-components to sub-components as time and resources become available.

Interconnectivity
Obviously, stand-alone systems are easier to reverse engineer requirements than systems that are tightly interconnected. A pitfall to this approach is the lure to document noncritical systems and components. If a system is critical and stand-alone, then starting documentation here is a good idea.

Data and Business Rules
An organization's data and how it's manipulated is very important. Reverse engineering data requirements and business rules can help identify redundant data usage. For example, you may discover different business rules are manipulating the same piece of data in different ways.

Finally, reverse engineering requirements wouldn't be complete without a central repository, which will allow you to define, simulate and validate requirements for all your systems. If you need to do total system documentation, then a repository will help you gather the requirements of the system, but also help you maintain any parallel changes to the system that you are documenting. If you choose to do incremental definition, then a repository will help you store and manage the ever evolving requirements to your systems.

Blueprint Deepens Integration with HP Quality Center !

Blueprint today announces the release of Requirements Center 2010 Feature Pack Two, further extending what is already the industry's leading integration with HP Quality Center. With this release the integration is now bi-directional meaning information flows in both directions between the two products allowing the rich definition features of Blueprint Requirements Center and the extensive management features of HP Quality Center to be leveraged iteratively, and at every point in the development lifecycle. The enhanced integration enables HP Quality Center users to communicate issues for further definition using Requirements Center, and then for HP Quality Center to receive the resulting requirement updates. Other enhancements include an expansion of information types that are populated into HP Quality Center including glossaries and business processes, and a new auto-save feature. Take a moment to see an overview of the Blueprint-HP solution followed by an on-demand demonstration.
If you have any further questions, as always just send an email to info@blueprintsys.com.

Can you hear me now ? Helping Business find their voice.

In an ideal world, excellent requirements result from a thoughtful, well-informed discussion between business stakeholders and professionals who provide the services and systems required to keep the business running and make it grow. Naturally, the conversation might require translation between the two sides, to ensure common understanding of business goals and technical details. Fortunately, there is the Business Analyst, whose role precisely addresses this difficulty.

So it's all good, right? Every company with a BA team produces excellent requirements arising from ideal collaboration between business and IT, right? Of course not, and I need not tell you that. What may surprise you is the extent to which business involvement varies across companies in the requirements definition process. In just the last two months, I have visited two customers who represent two extremes in how (or even whether) business should be involved in the process of defining IT requirements:
• Company A has a number of business issues, not the least of which is an ongoing loss of marketshare. In this company the LOB owners have a modest role in the definition or prioritization of IT requirements. On an annual basis, IT teams identify projects and technologies that are of interest to them, and then present the list of candidate projects to the business owners for their prioritization and approval. Once projects are approved, IT teams return to their labs, scope out their projects, decompose the scope into requirements, and build out the system. (In practice, these activities are rarely done in this order, and are sometimes done in parallel, but that is another discussion.) Meanwhile, business owners must figure out how the proposed system will help them achieve their business objectives. Whether they can or not, they are still going to receive the deliverable. The good news is that it will probably be on time, as their IT department takes great pride in its history of meeting project timelines. The bad news is that it may not provide any business value. As you can imagine, this is not working out well for this company. When I asked how this state of affairs arose, the customer blamed history and culture. "We're a technology-driven business. Business stakeholders aren't expected to be technologists, and tend to defer to IT on these questions. But we can't keep going this way. IT can't be expected to know what our customers want or need." Company A has asked us to help business find their voice in the requirements definition process.
• Company B has no in-house IT development staff. Instead, they assign BA's with specific domain expertise to various lines of business. BA's take requests (usually highly urgent ones) from LOB owners, package them into large specification documents, and contract with offshore vendors who complete the work. BA's at this company do very little requirements elicitation or elaboration, and focus mainly on completing specification document templates. The perception is that the requirements are fully described in the business case that justifies the request. Indeed, many of their "business cases" do read like specification documents. Business cases often include curiously specific requests like "We need a screen on the customer accounts page that looks like this..." without documenting the business need behind the request. LOB owners are dissatisfied with the length of time it takes to complete a project, and often submit a NEW! URGENT! request before their previous project has been completed. As you can imagine, their projects have a higher-than-expected failure rate in terms of returning targeted business value. BA's are frustrated by having to create such detailed documents without knowing the full story behind the requirement. They could provide significantly more value to the company than they do today. This company has asked us to help them structure the requirements conversation such that LOB owners can focus on high-value business initiatives rather than technical minutiae, and BA's can flesh out those initiatives into clear and complete requirements.

The good news is that, even for these extreme cases, the solution is the same. Requirements should depend on the business problem they are meant to solve. A company seeking to gain a handle on its requirements definition process needs to start at the topmost node in the hierarchy of business objectives. If the mapping has not been established and documented between a given project's scope and overall Business Objectives, the BA may have to return to the PM team and/or LOB owners for that mapping, and ask them to validate whether the project is in alignment with where the business is headed. Once this is in place, requirements can then be decomposed from general statements to the required level of specificity, be it to the point of writing textual requirements, use cases, screens, or an integrated model including all of these. The role of the BA is to drive this process and ensure that each requirement supports business goals.

 

I describe these companies as extremes on a spectrum, with Company A shutting their business stakeholders out of the requirements discussion, and Company B allowing business to thoroughly dominate the requirements and implementation discussion without active involvement from BA's or IT entities. In reality, these are manifestations of the same problem: a focus on the technology to-be-delivered, rather than on providing value for the customer.

In the case of Company A, this means that the requirements discussion can no longer begin with IT deciding which interesting things they'd like to develop in 2010. Rather, business stakeholders must define the path to regaining recently lost market share, then lay out a step-by-step plan for traversing that path. This plan will become a strategy document, against which projects and to-be-developed technologies will be weighed to ensure they support the strategy. In the event that projects in planning or development phases cannot be reconciled with the strategy, they should be scrapped. Company A will have some difficult and painful choices to make, but the alternative (continuing to lose market share) is not sustainable.

Business stakeholders in Company B already have such a strategy in place, but have not carefully mapped their initiatives to the strategy. And it is easy to see why: without an IT department that owns the design and implementation of the solution, their business people have adopted an affinity for the technical side of the requirements discussion, rather than driving business value. BA's will have to work hard to redirect business attention away from the implementation of a request, and towards the desired business objective. As with Company A, this will not be easy, but the benefit will be felt across roles:
• Business will receive valuable and relevant project deliverables.
• BA's will provide value by decomposing requirements from the business strategy into requirements statements, use cases, and (perhaps, but not necessarily) new or revised screens on the customer portal. In addition, their job satisfaction will likely improve, as their focus will turn more towards requirements themselves, and the information that goes into good specifications, rather than filling out templates.
• Offshore consultants will have much better artifacts to plan, carry out, and validate the business value of their work.
How well have you structured your company's requirements definition process? Symptoms of a flawed RD process include:
• One or another of these two examples strikes a familiar chord. (Or, Heaven help you, both of them do.)
• Features are often removed from and re-added to project deliverables.
• Projects do not deliver the intended business value.
• Projects are often late and/or over budget due to rework.
• IT teams find themselves providing similar or related services for multiple business units, but are unable to merge the projects.
• You laughed nervously at the Dilbert cartoon and thought, "That sounds familiar."

If any of these are true for you, your company might need some help in creating an RD process that provides the greatest amount of business value, and allows Business Stakeholders, Business Analysts, Development, Quality Assurance, Project Management, and other parties to focus on what they do best.

 

Big Freaking Requirements Documents !

The typical requirements document is a long, sprawling piece of literature. Within it, one might find a title page, table of contents, change history, complex headers and footers, legalese, confidentiality notices, and, if you're lucky, maybe even requirements. It's length is probably due to the fact that it tries to be everything to everybody. But the problem is that the document isn't read entirely by any single person, except perhaps by the analyst who wrote it in the first place.

And parts of these documents are only relevant to certain people. High-level overview stuff is great for managers, but developers could care less about the project's "vision"; and testers only require certain parts themselves. (Though one might argue that they should read this stuff, in order to provide context for the job at hand).

In theory, having all of the requirements in one document makes everything easier to find, as well, and to see how all the pieces fit together. In practice, however, the document becomes difficult to manage as it grows over time, and these linkages fall apart.

 

The question that I always seem to ask myself when take a peek at a customer's requirements document template for the first time is, "why must us humans unnecessarily complicate our lives like this?"

One of the core reasons, I believe, is that managers still want to put their monogrammed gold pen's ink on something tangible, sign on the dotted line, and have everything recorded so that somebody (namely the BAs that report to them) can be held accountable in case something goes wrong... which will happen, because nobody understood, or questioned the contents of the document in the first place.

Luckily, from where I sit, I believe that the typical printed requirements document is nearing its death. And the good news is that this eventuality is closer than most people think. Yes, for some companies this dream will be further away than for others, but Blueprint has actually witnessed this happening at some of the more progressive companies that we've worked with (thus restoring my faith in humanity).

Tools for the Business Analyst, like ours, help to take requirements and break them down into managable deliverables, suitable for consumption by various stakeholders with different needs, while *still* maintaining cohesiveness.

Tools for the Business Analyst? Better Late than Never

In the 90's the Standish Group with their "CHAOS Report" quantified the alarming rate of project failure in the software development industry and the associated costs businesses incurred as a result. It also identified poor requirements as a primary contributing factor. Over the last twenty plus years, the CHAOS Report has consistently told us that the project failure rate has not dramatically improved and poor requirements continue to play a leading role.
RM or Requirements Management was a term coined to cover the entire problem set at the time and a push was underway to convince development organizations to stop relying on office automation tools (Word, Excel, PowerPoint, Email) to document and communicate their project's requirements throughout the SDLC. Solutions such as DOORs, RequisitePro, and CaliberRM were introduced to the market as RM repositories. Textual requirements were typed directly into these tools instead of a Word document and they could be used to track each requirement's priority, status, due date, risk factors, etc. Edit histories were automatically recorded and trace relationships could be established and maintained between requirements for more meaningful analysis of both requirements coverage and the impact of proposed change. The focus moved from the document to the individual requirements themselves.
However, this early RM approach assumed the correct requirements were entered into the repository to begin with and that was a false assumption. As the old adage goes "garbage in, garbage out". It doesn't matter how well you version, baseline, trace requirements to each other. If the starting requirements are incorrect, incomplete or missing altogether then the team will surely encounter some unpleasant and very costly surprises further down the line.
RD or Requirements Definition was born of the acknowledgement that requirements had to be discovered and defined properly before they could be managed forward through the SDLC. As you might expect, solutions appeared in the marketplace to help facilitate the accurate definition of requirements: DefineIT, SteelTrace, and Profesy (later renamed "Requirements Center").
Additionally, there was focus placed on the visualization, prototyping, simulation of requirements to enable true validation that requirements are correct, complete, and aesthetic concerns, important to the business users, were not left to developers to figure out. Again, solutions like Apptero, Simunication, and others appeared on the scene.
Today the industry knows this collective space as RDM: Requirements Definition & Management and it includes visualization/simulation. However, the desired goal is not a collection of standalone products each addressing their own specialty but rather, a single integrated solution that addresses all of the challenges analysts face day to day, effectively becoming their workbench.
Developers have had their IDEs and integrated source code repositories for decades. Likewise, QA has had their test management and execution platforms for years. Finally, emphasis has been placed on the intrinsic importance of requirements and getting them right and the BA community will get the attention they deserve in the way of holistic solutions catering to their needs as a defined profession. It seems we're the last in line but better late than never.

 

Subject Matter Expertise - Take Your Medicine Wisely!

We've all seen the drug ads with the picture-perfect family playing Frisbee with the dog on the beach and the narrator telling us how your symptoms can be wiped away and usher in the dawn of a whole new healthy and contented lifestyle. Then the narrator becomes monotone as he reads at warp speed through a long list of pre-existing conditions that exempt you from taking the drug. Yes these drugs can be very beneficial but only under certain circumstances and in certain situations. If you take the drug outside of these circumstances it could actually cause more harm than good. I have a similar answer for people who ask if it's good for a business analyst to have subject matter expertise. In certain situations it can be a great asset, but in others it could actually be harmful.

The case "for" having subject matter expertise is pretty straight forward. The analyst doesn't have to be educated about the domain and can leverage his or her experience in the area and previous lessons-learned to the project's advantage.

There are occasions where it can actually work against the project's best interests. More than once I've seen subject matter experts who cut short the analysis that should be performed because they "think" they know the answer based on previous experience. Sometimes they're right - but many times they're wrong. In some of these situations I've also seen others on the project hesitate to challenge because the subject matter expert is supposed to be - well, the expert.

For a skilled and inquisitive business analyst to enter a project without subject matter expertise can actually be a benefit. Non subject matter business analysts have an open license to ask the so-called "stupid questions" and people have this expectation. These types of questions routinely uncover hidden issues that could have been disastrous later in the project. I've also noticed people can be more with this type of business analyst - possibly because they assume the business analyst knows less about the subject than they do so there's an element of feeling less threatened coupled with an natural inclination to help along "new comers" to the subject.

So should you actually try to steer clear of business analysts with subject matter expertise? Well, like the drug example, it depends. Before considering subject matter expertise, there are far more important skills a business analyst should have like being able to truly listen, facilitate, negotiate, and to have real analytical skills and modeling skills. To this I'll also throw in diplomacy and political savvy. Because vast majority of people I speak with agree with this, and after some discussion also agree that subject matter experience is lower in importance, what I find puzzling is why most ads for Business Analysts list subject matter expertise as the most important aspect of what they're looking for. Here's a sampling of ad headlines I just took from some online boards:

• Seeking strong BA with digital media and online content experience.
• Looking for Business Analyst with HR and Recruitment experience.
• Looking for Business Analyst with Vendor Management experience.
• Excellent Opportunity for ERP Business Analyst.
• Business Analyst - Investment Banking.
  

Perhaps as the profession continues to mature the key characteristics of what makes a good business analyst will become better known and sought after.

So if you're going to take subject matter expertise, here's my prescription:

• Before considering taking Subject Matter Expertise you should already have: listening, facilitating, negotiating, diplomacy skills, analytical skills, modeling skills and political savvy.
• Only take Subject Matter Expertise in combination with humility, true listening, and the liberal asking of ‘stupid' questions.
• Use the effects of subject matter expertise to probe more deeply, as a source of additional questions, and to help validate what you discover.
• Never rely on preconceived notions - do your analysis, and leverage your subject matter expertise to do better analysis.

BA World Ottawa - Should the PM be in the BA's business?

BA World Ottawa continues to be a great success with track sessions, panel discussions, and the final panel "throw-down" event.  The day started not with a keynote, but instead a series of round-table discussions on current BA Topics.  I think this is a great change-up to the traditional opening, is a wonderful way to initiate new connections, and a terrific way to kick-start the grey-matter first thing in the morning being an active participant rather than in listen-only mode.  

I was fortunate enough to moderate a round-table discussion on whether PM's should be doing BA-focused tasks.   The table included a wide variety of roles to my surprise.  There were of course BA's but also QA professionals, project managers, and even a trainer.  What emerged was a general concensus that the PM should be focussed on 'process' execution to drive the initiative while the BA needs to be focused squarely on what is to be built (as expressed by the requirements) and why (mapping to business objectives). 

Of course these two things are connected at the hip and you need to have very effective communication between the roles, but in essence each needs to focus on these two distinct aspects. The experience of the BA's at the table, each of whom had experienced a PM getting too far 'in their business' at one point or another, was that it happened mostly with new PM's or PM's who were insecure in their position and felt the need to micro-manage as opposed to simply being the result of poorly documented roles.   Another interesting experience was one whose company had a core group of BA's but would bring PM's in from the outside for each new project.  This meant that the subject matter expertise would reside with the BA and thereby limiting a PM's ability to go too far into BA tasks, and arming the BA with the information and knowledge needed to effectively 'push-back' on PM's who went too far.

All agreed that inter-role communication is one of the biggest sources of error on software projects.  Based on this it was proposed then that the ideal situation is when the PM and BA functions sit with one person so that there should be no communication issues.  One argument against this was put forth by another BA at the table who currently has a very good relationship with their PM and finds their ability to challenge each other on almost every aspect of the requirements and process would be lost if one person was doing both jobs.

There are clearly pluses and minuses to each arrangement and by the end the group felt that while each should focus on their core tasks (PM-process; BA-what&why) it would be more a function of the particular individuals involved and their ability to communicate and collaborate more than any other aspect that would determine how far they 'crossed the line'.