Tag: Business Analysis

Is there a “Place” for Business Analysts & Project Managers in Agile Teams?

Written by Robert Galen on May 7, 2013. Posted in Articles. 1 Comment on Is there a “Place” for Business Analysts & Project Managers in Agile Teams?

And if they belong there, what do they do? To be honest, I don’t exactly know.

It’s sort of the same question for other more ‘specialized’ roles like architects and operations engineers. They all don’t fit.

If I use Scrum roles as an example, there are ONLY three primary roles :

The Development Team
The Product Owner
The Scrum Master

That’s it. It’s simple and clear. There are no business analysts or project managers or testers or developers for that matter. There is only a team of individual skills that are tasked with executing a list of work—a Product Backlog.

They are asked to work together—producing “working code” in increments.

The team is self-directing; self-managing, and self-organizing. That implies that it’s pretty much up to the team to figure things out. Sure you can have managers hovering around the team and providing leadership, support and occasional guidance. But the best agile teams are pretty much left alone to deliver.

There is also the notion of generalization over specialization; in that you want the team to be as generalist as possible. For example, developers can design, write use cases or user stories, test, and deliver their functional contributions. So the broader each team member views their skill and responsibilities, the better. No hard silos allowed!

Call for Feedback

So, rather than my trying articulate whether they should or shouldn’t be in agile teams, I’m looking for reader feedback to generate discussion.

Do Business Analysts and Project Manager(s) have a place within Agile teams?
And if they do, what do they do? Seriously, what do they focus on?
How do they collaborate as part of the team? What are their primary roles? And contributions?
If they re-frame from “old role” to “new role”; what changes need to be made?

My sense?

My personal sense in both cases is that, yes, there is a place for Business Analysts and Project Managers within agile teams. Not leveraging their skills as they traditionally have, but more so transforming themselves to contribute within the context of an agile team. I would also argue that there are wider opportunities within agile teams to contribute.

But that’s just my perspective. What’s yours?

Thanks for listening,
Bob.

Don’t forget to leave your comments below.

It’s the End of the Business Analysis World as We Know It

Written by Steve Blais on April 16, 2013. Posted in Articles. 3 Comments on It’s the End of the Business Analysis World as We Know It

Where Does the Business Analyst Go From Here?

Being the serialized story of Brian Allen and Ann Brady, business analysts, and their Adventures in the New Oder of Agile

Chapter 1 How it began

Now he was concerned. Brian had weathered pretty much everything the organization could throw at a business analyst from the early days when he had to fight just to make the role a viable position in the organization to the past few years when he was under constant pressure to take over project management jobs in addition to his business analyst work. Brian was flattered that they felt that he had the capability to do both jobs simultaneously, but his heart was in business analysis and he was afraid that if he diluted his efforts by also managing he would seriously impair the enterprise level project he was on. Besides he had already done the project management thing. It was interesting and challenging, but it wasn’t what he wanted.

Now things were changing once again. The project he was on was a long term, several year reconstruction of one of the primary internal systems. It was one of the first systems the company had built to provide internal control over sales, marketing, order processing and just about everything associated with the organization’s backbone. The system was the pride and joy of the CIO, Carl, who was on the team that developed the system twenty years ago and it took some convincing, and a bit of arm turning, for the CIO to finally admit that the system needed an overhaul. Since he identified so closely with the system, it was as though he himself needed an overhaul. As a result, Carl also looked at the way the organization had been developing software over the years and despite a highly successful record of on-time delivery, at least on the internal mainframe based systems, the CIO decided that perhaps the organization should segue into agile.

The web site maintenance had converted to an agile approach to software development a few years back and been successful after some bumps. There were some teams here and there on the periphery of the internal systems that were run with an agile approach, mostly in maintenance activities. But the primary systems, based on the trusty IBM computers and written in Good Old COBOL, with a smattering of Assembler Language Code, were still maintained in a structured software development approach patterned after the linear, waterfall, model. Major new efforts, like the overhaul of the purchase order system which took two years was also done the traditional way.

Since the entire backbone system of the organization was going to be rewritten – code, databases, architecture, even some new networks – Carl had decided that everything might as well get more “modern’ as well. They were even relocating various offices and departments.

So Brian was worried. He and Ann were the lead business analysts in the organization and from his understanding of agile and its mystiques; he was looking at the end of his career as a business analyst in the organization. Neither he nor Ann wanted to leave. Their roots ran deep in the organization. But Ken, the leading Scrum advocate, who had led successful Scrum teams and Theresa, the technical lead, who was a staunch Extreme Programming (XP) advocate, were both onboard with the software development conversion and had advised Brian and Ann independently that the services of the business analyst were no longer required in the New World.

It wasn’t pretty. Brian still shuddered when remembering the show down meeting when the CIO decided to give the green light to the New Order of Development. What was ironic was that Brian had been a vocal proponent of the overhaul of the old system and was instrumental in influencing the CIO and executive committee to launch the new program that appeared to signal the death of his own job. Brian in fact, with Ann’s help, had written the successful business case!

Brian, of course, protested loudly in front of Carl, Vince, the Vice President of Marketing and heir apparent to the CEO’s job, and Olivia the Vice President of Operations, asking how the teams were going to determine what they had to do for the new system.

“Do any of your programmers have experience with inventory turns or balancing a cash receipts journal?” Brian had taken accounting courses and even a CPA overview from the state CPA association to keep up to date on accounting.

“They don’t have to be experts,” Ken countered. “We have the experts in the business who can tell the developers (he emphasized the word to remind Brian how out of touch he had become) what needs to be done. It’s not a problem. It’s time the developers and the business cut out the middle man, er, person (acknowledging Ann) and let the solution meet the problem directly.”

Ann spoke up. ”I’ve spent years with both the developers and business people. I don’t think the developers care to sit in long meetings and discuss the intricacies and ambiguities of supply chains and customer service. They have always preferred to just get the facts: what they have to do to solve the problem.”

Ken responded before Ann could finish. “This is the New Order, Ann. The developers are going to get with it and learn about the business. They are going to learn negotiation and interaction. Things are changing. We’re taking the developers out of their development hovels and moving them across the aisle.”

“Even if they don’t want to go? Even if they prefer just to code?” Brian asked remembering the days when he started out as a programmer and worked with many peers who really didn’t want to talk to anyone in the business.

“Yes,” replied Ken. “That is the Way of Agile.” He said it with a slight reverence as though talking about an Eastern Philosophy like Zen. Brian thought he saw Ken put his hands in front of his stomach and bow slightly with a Yin and Yang symbol hovering over his head.

Ann recovered the floor. “And I have not seen many of the business people who will jump at the chance to spend all their time with the developers and sacrifice their daily jobs. They don’t understand how the developers need to hear the specifications. They don’t understand how to specify requirements.”

Ken, in his enthusiasm, jumped in again, “They don’t specify requirements. Requirements are dead.” Brian thought he heard an underlying meaning in that statement: “Business analysts are dead along with the requirements.”

Ken explained, “We use user stories now. We don’t do requirements. Not only are requirements inefficient, tedious, generally unworkable, and unreliable, they are also boring. User stories are easy enough even users can do them. And we are also making the whole burdensome change management system that has infiltrated everything in our culture obsolete. No more green and pink forms, no cumbersome on line system that people forget to update, no endless change management meetings with the CCB that doesn’t want to be there in the first place, no politics,” Ken’s voice was raising, sounding like a politician in front of a Labor Day political rally crowd. “There will be no more risk management exercises with a Risk Register maintained by a Project Administrator, no Earned Value graphs and charts and reports, and, consider this, sir,” he said addressing Vince, “no more project managers or PMO.”

Ken, and everyone on the table, knew that the PMO and to a large degree the whole project management structure of the organization had been a thorn in Vince’s side for years. Vince hated the paperwork and time consuming processes that the PMO had established to provide some semblance of control and prioritizing of the projects in the organization. Vince was known to protest loudly to anyone who would listen, especially his golfing buddy, Charles Evans, the CEO, “We’re losing ground to the new and faster and more agile competitors out there. They get to market much faster than we do. They have a more agile approach to product development. When we come in with a change, it’s either in response to a competitor’s move or to market demand. If we don’t act fast we lose market share (market share was an important issue to Charles). If I have to go through all this paperwork and committee approval and business analysis and requirements and stuff…it takes longer to get something approved than to just get it done!” And unfortunately, Brian knew that was true to a large degree, but he was also around in the old days when everyone in Management Information Systems (MIS), as it was called then, seemed to be working on the demand du jour with no order or priority or sense. Efforts were introduced and dropped, replaced by other initiatives from executives with higher political clout, or urgency, and then brought back out of their hiatus with the admonition that they should already have been done. It was chaos. Projects failed not because they were mismanaged but because of the conflicting priorities and the disorder in the assignment of resources and the frenetic communications channels. Everyone in the organization could talk to any programmer at any time to get anything done. Brian was somewhat proud of the work he and Ann had done in bringing order to the business process of managing organizational change. He never took Vince’s complaints too seriously because the system was working fine for the rest of the organization.

It was then that Brian realized that Ken was in cahoots with Vince and had Vince’s complete support for the New Order. And Vince, as the next CEO, had the political clout. It looked like the Organizational Change Management system that had run successfully for these many years was as doomed as well.

“And as for the business people, they will love being able to get their needs met immediately in the order that they want them met. They will be able to change their mind, change their needs, change their approach, try new things and then try something else without the imprimatur of fighting the system to get things done. We see a major increase in innovation because the barriers to creative failure will be removed.”

Brian wondered where Ken had picked up the phrase “creative failure”. He knew it won points with Vince.

Brian and Ann fought to hold down their frustration. They lodged all the objections they could muster, but to no avail. The New Order was coming to the Organization. And that meant that there was no place in the New Order of Things for either of them or any of their cohorts on the Business Analyst Team that he and Ann had struggled so long to set up.

Brian’s thought, unexpressed to Ann who was lost in her own downtrodden thoughts, was “I’m way too young to retire, and way too old to start over again in a different organization or a different career. Besides, I really, really, really love being a business analyst.”

Brian was now being summoned into Pauline’s office. Pauline was the head of the PMO to which the Business Analyst Team reported. As he walked down the corridor which seemed a lot longer this morning than ever before, feeling like he was walking to his own execution, he was wondering, “what happens now? Is there no place for a business analyst in the New Order of Agile?”

With a shudder, Brian gathered himself together and opened the door to Pauline’s office.

“Ah, Brian,” said Pauline, not really smiling. “We have to talk. I’ll be talking to Ann next.”

What is going to happen to Brian facing the Perils of Pauline? Will the Business Analysis Team and the Change Management System survive? What about Ann and the rest of the business analysts in the organization? Join Brian, Ann and the rest of the Business Analyst Team in the next episode of Brian and Ann and the New Order of Agile next month.

Don’t forget to leave your comments below.

Excerpted from the forthcoming book from John Wiley, The Agile Business Analyst due out the end of 2013

How to Fill the Potholes in your Business Requirements

Written by Amanda Bennett on April 16, 2013. Posted in Articles.

It is springtime in Ottawa, Ontario, Canada. Beautiful, glorious, Spring! Everywhere you look, the signs are there: frozen rivers are starting to flow, birds are returning and filling the air with their sweet melodies, snowbanks are shrinking, and…oh yes, potholes are showing up everywhere in the roads. As much as I try to avoid them, somehow they always get me. It takes a special breed of car to survive the tough Canadian winters. My Honda Civic is on it’s 10th year, 161,000 clicks, and still going strong.

Trying to avoid the springtime potholes is a fair analogy to a task that I am often asked to do as a Senior Business Analyst: reviewing and providing constructive criticism on business requirements written by someone else. A road filled with potholes can wreck your car, just as a poorly written set of business requirements can wreck a project. My job when reviewing business requirements is to look out for these potholes, make the writer aware of them, and provide suggestions on how to fill them.

Digesting business requirements written by someone else can be challenging, depending on the writers experience, knowledge, and ability, so to make things somewhat easier, I provide a template for my clients to use. Before they start their requirements, I will meet with them to explain how to use the template and to discuss any questions they may have. Using a template, I at least know the intent of all the sections of the document, and it gives a greater consistency to the documentation I have to review.

Once the written requirements are sent to me for review, I start by analyzing the document from beginning to end. One of the first things I look for are acronyms or business terms that have not been defined. This usually happens because the writer thinks that they do not need to elaborate on the use of terms internal to their business unit, but they forget to consider the audience of the document they are writing. Clear and unambiguous definitions of business terms are especially important to the developer, as they can have a direct impact on how they architect the system.

I also pay a lot of attention to the process diagrams of the current and future states. It is a very common mistake to omit the alternative paths to a process. It is understandable how this can happen. People assume that because the process usually happens a certain way, that they do not need to mention the other rare scenarios. Others may think they only need to describe the perfect world scenario, and forget to think of all the what-ifs. For a manual (non-computerized) process, unusual scenarios can be dealt with simply by communicating with those affected. When the process goes electronic, it is another story. The programming logic has to include all the alternative paths, or the system could fail spectacularly. This is a mind-shift for people that can take some getting used to.

When I am ready to dig into the detailed requirements, there are a few things I am on the lookout for. First of all, what I do not want to see are long, wordy paragraphs with several requirements buried within it. It may feel more natural to write this way, but not only is it painful to read requirements this way, it also greatly increases the likelihood that a requirement will be missed somewhere along the way, either during the development, or in testing. A much safer practice is to write each individual requirement separately, and give it an identification number. That way, even if a requirement does get missed during development, it will get picked up in the testing, assuming your test scripts have appropriate requirements tracing as well! That’s the topic of another post.

Secondly, I want to see a clear link between the in-scope deliverables laid out in the project charter, and the detailed business requirements. This is so important, because people can and will forget (perhaps conveniently sometimes) the original goals of the project, and before you know it, the scope of the project has grown exponentially. Believe me when I say, this is a crazy train that you do not want to be a passenger on. To create that linkage, what I will do is ID each of the in-scope deliverables, and use them as the parent IDs for the detailed “child” requirements. That way you know where each requirement is coming from.

Finally, I watch out for requirements that delve too deeply into design details without properly explaining the need behind it. This is a risky thing to do because when describing design details as a part of requirements, you limit the technical architect’s (or whatever you call that role) ability to design the best system to meet the client’s needs. That said, there may be cases where a specific design may be warranted, but the reason for that should be explained clearly. There are, in fact, some people who feel that requirements should not contain any design details at all, and only state the need. Others feel that not only is it ok to include design in the requirements documentation, but fully expect it. This is a contentious issue that I will not attempt to resolve here, but suffice-to-say that you should do your homework before you start writing your requirements. Find out what the practice has been in past projects, and what is expected of you now.

While this is not an exhaustive list of everything I am on the lookout for when I review someone else’s business requirements, this represents the bulk of my work. Hopefully you’ve read something new in this post, or at least can relate to what I’ve written.

If you would like to weigh in on this topic, please leave your comments below.

Business Analysis in the Modern Full-Service Agency

Written by Neels Ackroyd on April 9, 2013. Posted in Articles.

Since the 1970s, the role of Business Analysis in software development cycles has gained significant importance. However, the presence of the business analyst has also grown in the web development sphere (especially in larger agencies), but the exact role still overlaps in many departments within larger agencies. This article focuses on the Business Analyst’s role in web and digital development.

The diagram below depicts a typical agency workflow, with the inclusion of the Business Analyst’s role:

Essentially, the onus of a Business Analyst in an agency is to create a functional specification to:

Define the scope and get sign off from the client
This is to eliminate the catastrophe of the lack of agreement between the client and the agency, especially in terms of system functionality and general scope. This can cause immense strain and stress between an agency and its client. Typical strains include resources that have to be rebooked, budgets that dry up, demotivation from production teams and late delivery within the client’s space.
Define guidelines to developers and designers
Functional System Specifications have to be fleshed out in the most detail possible for other team stakeholders such as designers and developers to be fully aware of all the system specifications.

From a design perspective: Ultimately, a wireframe should never limit the designers’ creativity, but rather encourage further innovative thinking by providing a framework for creativity. As reality speaks, budget and time are always on the scale, which does not mean creativity must be undermined, but rather controlled. Designers are thus still allowed to use the wireframes as a guideline, rather than a system set in stone.
From a development perspective: Functionality is defined and finalised upon sign-off of the Functional System Specification. It is therefore the duty of the technical lead to ask all questions before the document is delivered to the client. Having said this, if functionality changes due to improvements during design (or other discoveries), then change requests have to be written as addendums to the signed off functional specification.

It is very beneficial for Business Analysts to have a development and technical background so that best practices (for example technology preferences and database design) can be proposed. It also saves time for developers due to development groundwork that is done before development commences.

In conclusion, it is clear that the Functional System Specifications can be used in the master document for Production and if followed correctly, it will save the agency and the client a great deal of money, time and energy.

In my next article I will discuss best Functional System Specification guidelines for the modern digital agency.

Don’t forget to leave your comments below.

The BA Practice Lead Handbook 5 – Getting Organized. What Structure is Right for You During the Start-up Phase?

Written by Kathleen B. Hass, PMP on March 19, 2013. Posted in Articles.

A center of excellence is a team of people that is established to promote collaboration and the application of best practices. Centers of excellence are emerging as a vital strategic asset to serve as the primary vehicle for managing complex change initiatives.

Centers of excellence exist to bring about an enterprise focus to many business issues, e.g., data integration, project management, enterprise architecture, business and IT optimization, and enterprise-wide access to information. The concept of centers of excellence (COE) is quickly maturing in twenty-first century organizations because of the need to collaboratively determine solutions to complex business issues. Project management offices (PMO), a type of COE, proliferated in the 1990s as a centralized approach to managing projects in response to the challenges associated with complex projects in an environment with low levels of project management maturity and governance.

Business Analysis Centers of Excellence

The business analysis center of excellence (BACOE) then, is an emerging best practice, a new type of center which serves as the single point of contact for business analysis practices. In that role, the BACOE defines the business rules, processes, knowledge, skills and competencies, and tools used by the organization to perform business analysis activities throughout the project life cycle, from strategic planning to project initiation to solution delivery and benefits realization.

As the discipline of business analysis becomes professionalized, it is no surprise BACOEs are quickly emerging. Staffed with knowledgeable business and IT team members, these centers are fulfilling a vital need in organizations today – providing a business-focused home for current business analysis practices, technologies, and emerging trends. The BACOE serves as an internal consultant and information broker to both the project teams and to the executive management team. In addition, the BACOE is responsible for continuous improvement of business analysis practices. To that end, the BACOE continually evaluates the maturity of business analysis and implements improvements to overall business analysis capability.

Implementing the BACOE

Referring again to the BA Practice Framework, we assume you have completed the Readiness Phase, and are now ready to begin to implement the BACOE.

There are several models of BACOEs that are in existence today. Each structure has unique composition, goals and outcomes. The type of center that is most appropriate for your organization depends heavily on the culture, power and politics that exist within your organization. Common BACOE structures include those described in the table below.

BACOE Scope

A truly comprehensive BACOE is broadly scoped to include the services, functions, tools and metrics needed to ensure the organization invests in the most valuable projects, and then delivers the expected business benefits from project outcomes in terms of value to the customer and/or wealth to the organization. A full-service BACOE typically performs the functions described below.

A fully functioning BACOE is capable of providing services across the gamut of business analysis practices. The BACOE mission and objectives are met through training, consulting and mentoring business analysts and project team members, by providing BA resources to the project teams, by facilitating the portfolio management process, and by serving as the custodian of BA best practices. The BACOE generally performs all or a subset of the following services.

• BA Standard Practices and Tools – provides standard business analysis practices

- Methods – defines the methodology, metrics and tools for use on all strategic projects within the organization.
- Knowledge management – maintains the central historical data base of business analysis standard tools, processes and business architecture components
- Continuous improvement – periodically evaluates the maturity of the business analysis practices within the organization, and implements improvements to policies, processes, tools and procedures

• BA Professional Development – provides professional development for business analysts

- BA career path – along with the Human Resources Department, designs and maintains the BA competency model including titles, position descriptions, functions
- Coaching and mentoring – provides mentoring services to BAs and project teams to help them meet the challenges of their current project
- Training and professional development – provides formal skills and knowledge assessments, and education and training for the professional development of BAs
- Team building – provides team building experiences to project managers, business analysts, and team members

• BA Professional Services – serves as a group of facilitators and on-the-job trainers who are skilled and accomplished business analysts to provide business analysis consulting support including:

- Conducting market research, benchmark and feasibility studies
- Developing and maintaining the business architecture
- Preparing and validating the business case
- Eliciting, analyzing, specifying, documenting, validating, and managing requirements
- Managing requirements verification and validation activities, e.g., the user acceptance test
- Preparing the organization for deployment of a new business solution
- Providing resources to augment project teams to perform business analysis activities that are under-resourced or urgent

• Full Cycle Governance – promotes a full life-cycle governance process, managing investments in business solutions from research and development to operations. Provides a home (funding and resources) for pre-project business analysis and business case development.

- Business program management – works with management and the portfolio management team to implement a twenty-first century model that transitions organizations from stand-alone IT project management to business program management.
- Strategic project resources – provides senior-level business analysts to lead the business analysis effort for strategic initiatives.
- Enterprise analysis – provides process coordination and meeting facilitation to the portfolio management team. Conducts enterprise analysis activities and prepares the project investment decision package consisting of the business case, the results of studies and other supporting information that provides senior management with a clear understanding of what business results are to be achieved through a major investment.
- Benefits management – Measures the business benefits achieved by new business solutions; facilitates the adoption of a shared vision of the benefits realization process, manages the investment throughout the project life cycle and after the solution has been delivered.

Putting it all Together

So what does this mean for the Business Analyst?

Today’s BAs are performing their duties in a myriad of organizational environments. Determine where your organization is on the continuum and get involved in moving your BA practice to the next level.

So what does this mean for the BA Practice Lead?

This article presents the case for a BA Practice Lead to examine the organization to determine the best fit for the BACOE. Perhaps a less formal COE is appropriate at this point in time to build the foundation and credibility needed to implement a formal BACOE. Leverage the existing structures and power bases to launch your BACOE, constantly demonstrating the value of a mature BA practice.

Parts of this article are adapted with permission from The Business Analysis Center of Excellence, The Cornerstone of Business Transformation by Kathleen B. Hass, PMP, Richard Avery, Terry Longo, and Alice Zavala. © 2007 by Management Concepts, Inc. All rights reserved.

Don’t forget to leave your comments below.