The Role of the Analyst in Agile Projects

| Posted by Shane Hastie Follow 28 Followers on Dec 05, 2008. Estimated reading time: 11 minutes |

There is a gap in much of the literature about Agile software development practices, and on many Agile teams. This gap is the role of Analysis in Agile projects - who does it, what is the use and value, and how does it change? The implied (and I have heard stated at least once) attitude is "we don't need no stinkin' analysts" - needless to say I feel this is WRONG! In this article I make the case that the Business Analyst can play a useful in relation to Agile teamwork - when properly aligned with the business, rather than with the development team, as is too often the case.

Why be Concerned with the Business Analyst Role?

It is my contention that, without the analyst, real gaps occur. For example:

  • Who looks at the bigger organizational problems?
  • Who identifies the underlying conflict between what management want (the Customer who pays for the software development, after all) and what the "Users" (a horrible term - but that will be the subject of another discussion) need in order to do their jobs effectively?
  • Who identifies the fact that there are (say) 1500 people who are currently doing their jobs in one way, and that after we've implemented the new software will need to significantly change their work patterns?
  • Who helps these people design new organizational procedures to ensure that the business continues to run smoothly as the changes are made?
  • Who identifies the potential lost business due to a poorly thought out customer interaction?
  • I could go on, but you get the picture.

Alan Cooper gave a great talk recently at the Agile 2008 conference wherein he spoke with passion about the need for inclusion of Interaction Design in Agile projects, someone who understands how people behave and who can help the Customer come up with guidelines for the technology implementation to ensure that the resultant product works effectively in real-world use.

My contention is that this role is one which is ideally and effectively undertaken by the Business Analyst, and is something that we should have been doing all along. It is part of what we are trained for - understanding the broader business needs and interpreting these needs in ways that make sense to team members who are more focused on the technology. Traditionally the custodian of the focus on the human need has been the Business Analyst.

Business Analysts Contribute to Team Success

I strongly believe that the de-emphasis of the importance of this role is one of the major gaps in many Agile teams today. In many organizations the analyst role is hobbled - unable to effectively deliver the value they promise due to organization structure and lack of management support. The business analyst needs to be seen as the customer advocate, part of the business-focused solution provision team, rather than a purveyor of technology. Politically empowered, trusted and acknowledged for the perspective and understanding they bring, the business analyst should ideally report into a business improvement area, not into the information technology group. In this structure the business analyst will be empowered to recommend changes with a clear focus on the business value, rather than being perceived as the "lackey of technology" as part of the technology group.

What about Systems Analysts?

Note the distinction here: we are talking about Business Analysts, not Systems Analysts. Where does the "Systems Analyst" fit? While the systems analyst often has the skills to undertake business analysis effectively, I make a distinction between the two roles based on their perspective - the business analyst focuses on and is driven by an understanding of the business needs whereas the systems analyst is often biased towards, and focused on, a technology-based solution, sometimes to the point of being detrimental to actually solving the business problem ("Wow, have I got a solution for you!"). Systems analysts can be good business analysts, but they need to be very careful to suppress their urge to propose technical solutions!

Why Use an Analyst? We Want a "Customer"

The analyst spends time getting close to the diverse "stakeholders" - people who represent groups and organizations that care about the successful delivery of the business change. The analyst needs to understand the multiple dimensions of the business need; discussing with management the overall goals and objectives; working with the legal department to identify any legislative or litigious impacts of the new/changed business processes, working with the logistics department to identify changes to office space or warehouse layout and to understand the potential impact of the processes on the flow of materials or products through to dispatch; with the administrative staff to understand the potential bottlenecks that could result from a new approval process... and so on.

At some point in the analysis investigation it will become clear that solving this business problem potentially warrants an investment in technology. At this point the analyst role changes a bit and we get involved in the technical feasibility discussions - the "build vs buy" decision, the insource or outsource decision. At this stage traditionally the BA role is involved in developing the Business Case, which is still needed by the business when using the Agile approach - projects still should be justified in terms of the business benefits they will deliver to the organization. Without this valuation, the ongoing prioritization effort required for Agile backlog management can lack "big picture" vision, resulting in requirements thrash.

Once these decisions have been made and it is decided to spend some money on the technology, the analyst role changes yet again - now we become the shepherd of requirements; the collector and guide of stories. This is where the analyst actively intersects with the Agile project and becomes a vital participant with the Agile software development project team, representing customers and end users, and collaborating with the other team members to meet a clearly identified Business Need which we believe will benefit from a technology-based solution.

The Analyst works with the project team to corral the stories - acting as the customer advocate to the team, facilitating User Story definition, and being the project advocate to the wider stakeholder community, taking responsibility for getting the right customer voice to the project team at the right time. This "customer", so blithely referred to in much of the Agile literature, is not usually a single homogeneous individual, rather they are an amorphous mass of "stakeholders" - a diverse, often contradictory, frequently competitive, sometimes negative group with divergent points of view about what the business need is and what "done" looks like.

Does the previous paragraph imply that I don't believe in the "on site customer" - NO! I believe very strongly that we need an onsite customer for the Agile development process to be successful. The challenge we face is that there will be many customer voices, often shouting contradictory orders at the team. The Analyst must be able to filter the signal from the noise and help to identify the right representative customer(s) who should be involved with the project at any point in time.

So What Does this Analyst Actually Do?

On an Agile project, the Analyst also becomes the shepherd of stories - guiding the discovery process and facilitating the communication among the team, helping the customer representative(s) by asking probing "what if, what about" type questions, based on the broader investigation which initiated the project; building on their mapping of the stakeholder community, their understanding of the intricate political and influence relationships which underlie the formal structure of the organization and their ability to tap into funding sources to gain access to real-world clients (the people who actually pay for the services the system will provide) to gain an understanding of what is needed to create competitive advantage and Customer Delight - which ultimately results in commercial success.

The analyst needs to have a broad range of investigative and interpersonal skills, the ability to think critically and skeptically, using a variety of modeling techniques and other tools to help the customer representatives discover the range of stories which will ultimately make up the system. The analyst helps them express these stories in clear and understandable ways that make "done" explicit and knife edged, works with the testers and customer representatives to help identify and clarify the acceptance criteria for the whole gambit of stories.

The best analysts are involved in every aspect of story identification, and actively involved in the interaction design for the system. They have an understanding of the various ways the broad community of users will need to interact with the system, understanding the divergent needs and smoothing the differences to identify the design aspects which will work for the disparate stakeholders.

Agile Analysts are Designers as well - with an understanding which goes far deeper than simply identifying and documenting the requirements for the system. They understand the implications of screen flow and ensuring that process flows match the way people actually work, they are aware of the impact of colors and fonts, of screen layout and response times on the productivity of the people who use our systems. They look for opportunities to create truly useful systems that people want to work with, and work to guide the creation of intuitive and natural interfaces; ideally interfaces that seem to disappear, so easy to use that the operator doesn't even notice that they are there.

The traditional analysis "what before how" approach doesn't apply on Agile projects - most often we understand the "what" by showing the "how", in a productive and iterative cycle that is an inherent part of the Agile development process.

Look and Feel matters - the Agile Analyst helps bring this into sharp focus when the interaction aspects of the system are being worked on.

The Agile Analyst focuses on ensuring that real business value is exposed and uncovered by working with the project team and customer representatives to find those aspects which make their work easier, more productive and deliver Customer Delight, the "stickiness" which keeps our clients coming back to do business with us over and over again.

Who Should Play the Analyst Role?

The Product Owner or chief customer advocate in a Scrum project is a role ideally suited to the Agile Analyst, provided they are empowered and supported to act on behalf of the customer. The Analyst is in the position to actively manage the product backlog and identify product priorities. Building on relationships with business stakeholders and an understanding of technical realities the Analyst can actively manage the delivery of value in the project.

The Agile Analyst needs to be an active and productive member of the business project team, not trying to produce a lengthy tome of "shall" statements, but representing, advocating and shepherding the many customer voices, asking the hard "have you thought about. . ." questions, ensuring that the products we deliver meet the diverse and competing needs of our customers, understanding and indentifying flaws, flows and issues with discussions and interactions within the entire project team, based on the User Stories current and past.

The Analyst Role is Necessary for Success

Technology exists to serve, not to be, the human need!
-- Malcolm Watson, the Development Manager at Pronto Software in Melbourne

The Business Analysis community needs to step up to the mark - becoming active participants in collaborative Agile teams focused on the creation of systems that deliver real-world value and Customer Delight. An active move back to the "Analyst" part of the role - breaking the problem apart into its constituent components in order to understand the real underlying needs, then working as an active participant on the project team to deliver a solution that creates competitive advantage and customer delight!


Sidebar: Who is this "Analyst" I'm talking about here?

The International Institute of Business Analysis (IIBA) states that the business analyst "works as a liaison among stakeholders in order to elicit, analyze, communicate, and validate requirements for changes to business processes, policies, and information systems".
The role of the business analyst can well be described as the "universal communicator" – understanding and representing the diverse stakeholder perspective in a clear and articulate manner, assisting business people in the discovery process whereby emergent and unclear business needs are uncovered, and the real value adding requirements are identified.

This role transcends the development methodology being used, and the latest version of the BABoK™ (Business Analysis Body of Knowledge) explicitly acknowledges the value and importance of Agile techniques, and the way the business analysis activity changes in Agile projects.


About The IIBA

The International Institute of Business Analysis is a professional body that describes themselves as "The world's leading association for business analysis professionals". The IIBA has 78 chapters in 13 countries around the world, with 7128 active members in 44 countries, and its mission is "To develop and maintain standards for the practice of business analysis and for the certification of its practitioners".

The IIBA publishes the BABoK™ - the body of knowledge that identifies the broad skills and competencies a professional business analyst should have. The BABoK™ is methodology agnostic, and in version 2.0 explicitly acknowledges the important contribution Agile methods make to the development of software solutions to business problems.

The IIBA provides a certification program for business analysts, the Certified Business Analysis Professional (CBAP™) which is based on proving experience in the field and knowledge of the BABoK™ knowledge areas.

About the Author

Shane Hastie is the Chief Knowledge Engineer at Software Education - a training and consulting provider based in Australia and New Zealand. He teaches courses and provides consulting services in: agile techniques; software project management; business analysis; software testing. Shane is a Certified Business Analysis Professional (CBAP™) and in 2007 completed his Masters degree in Information Management. His Master's case study examined the benefits obtained through implementing Agile methods at an ERP vendor in Australia. He is also a certified ScrumMaster (effective 2 Dec 2008). Shane has 25+ years experience implementing technology solutions to business problems, covering a range of industries from financial institutions to airlines, pharmaceutical companies, facilities management, fleet managenent and telecommunications.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Customer Engagement by Paul Beckford

I've heard talk like this about "key roles" before. I remember all the talk about the role of "the architect". Who are these people? Where do they come from? My experience tells me that you just can't parachute people into an organisation to solve all your problems.

The people who benefit from software need to take ownership and be engaged in its creation. So someone in the business needs to do some analysis, and needs to act as a product owner. Of course this person can benefit from coaching and/or professional help, but he/she can't side step their responsibility and pass it on to the BA.

I'm not sure defining all these roles help. In my mind there are just two roles. People who want software and people who build it.

A strong product owner who knows what he wants and why he wants it is key IMO. If he isn't sure then he can learn on the job using feedback and trial and error. Not perfect I know, but at least the mistakes are his mistakes and the business can then learn and grow through experience, rather than blaming the hired help.

As far as the business is concerned the BA will always be an outsider. The BA is not on the hook to deliver business results. The BA is not a business leader.


Analysis is needed. Analysts... not necessarily. It boils down to people by Przemyslaw Pokrywka

I fully agree with Paul with regard to customer engagement.

Moreover, while I think, that some healthy amount of analysis is helpful, having a separate analyst role is not.
For me, it's good, that the article draws attention to analysis tasks. If you omit them, you risk some missed opportunities.
It is often being forgotten, that agile movement was started by higly experienced and skilled software professionals. Many unexperienced agile adopters lack some basics of software engineering (poor OOP skills are most cited, but not only - SCM is often practiced in poor way). You have to assume, that analysis skills are not on highest level in most of places too. It is always needed to remind of the very basics and to evangelize the best practices.

Analyst role is a different thing, though. Analysis should be divided between the customer and the development team IMO. When you place a new role between customer and development, communication suffers. Even if the analyst is the best communicator, she will always be a middle-man. Thus, unnecessary costs are generated. This is one of the problems. Another is a temptation to "throw things over the wall" and valuing processes and tools more than individuals and interactions.
Several other problems exists too.

Lets focus on tasks not the role of the business analyst by Sachin Mehra

Lets associate the task performed by the analyst with product, not a role. Anything that can be done to add business value to the product or deliver the (so called) "right" product is PO's responsibility.

PO being the customer representative, is expected to know what's best for the business. Team will definitely ask questions to get clarity on the items in backlog, as well as suggest things to consider. Together they both will uncover the true business needs.

In my opinion, if business (customer) does not give time for developing the product, no BA can help. When business get involved, PO is enabled and empowered with right information and business knowledge to think on its behalf...faster and better than any outsider (read "BA").

Pros and Cons by Stephen Palmer

I agree with the importance of analysis in any sort of software development effort. The idea that customers with little experience of working with IT development teams can simply turn up and produce a good product backlog/features list/, etc. is optimistic in my experience.

This is especially so, if the IT development team are inexperienced at agile themselves and are trying to go it alone to save the cost of employing an experienced agile coach/scrum master.

An experienced BA working with a customer in the product owner role to help them think through what the business needs and the business value of functionality can be very useful indeed and save a considerable amount of time. However, knowing when to stop is very important. Prolonged detailed discussions between the BA and the customer without the development team present misses the opportunity to communicate vital domain understanding to the development team, and possibly the opportunity to provide a truly innovative solution.

Feature-Driven Development includes domain-experts and developers in such discussions during the building of an initial, overall model of the problem domain.

In Scrum there is work to be done to prepare an initial backlog, and the role of Product Owner requires ability, discipline and experience. Assigning a Business Analyst to this position after applicable training would seem the intuitive thing to do. However, it may immediately introduce a level of indirection in communication between the paying customer and the development team.
The point that the analyst should report through the business side and not IT is, therefore, well made but not fool proof.

There is still the danger that the customer may view the assignment of the BA to the PO role as fulfilling their part of the project responsibilities. A key clue that this is happening would be if the customer stopped attending end of iteration reviews saying that the BA/PO is able represent them. Another would be if the customer is surprised by what is demonstrated at an end of iteration review or starts debating with the BA/PO over 'requirements'.

I believe the role of analysis is vital, and that a good business analyst is of benefit to any team. However, the temptation for an experienced analyst to slip back into being a buffer between the IT team and the customer, enabling each to become lazy in communicating with the other is a constant danger.

Re: Pros and Cons by Paul Beckford

I believe the role of analysis is vital, and that a good business analyst is of benefit to any team. However, the temptation for an experienced analyst to slip back into being a buffer between the IT team and the customer, enabling each to become lazy in communicating with the other is a constant danger.

In the end it depends on the culture of the organisation and the individuals involved. So I agree that its not black and white. In terms of risk, I'd rather take the risk of having a less then perfect backlog that was clearly owned by the customer (business), then an impressive backlog that was perceived as being owned by a BA.

Why? Well it comes down to leadership. Software aside, businesses have an obligation to perform. If a business is under performing, whether through inappropriate software or any other reason then the business leadership should be clearly accountable. So clearly placing the responsibility for leadership where it belongs avoids the blame game.

Clear responsibilities also creates an opportunity for improvement. If it is clear that the business as underperformed in defining the software they need, then the business can learn from the experience and improve in the next release. If its seen as the BA who has underperformed, then the business will never learn.


A solution in search of a problem? by Dave Nicolette

"I strongly believe that the de-emphasis of the importance of this role is one of the major gaps in many Agile teams today." Your article convinces me you are passionate in this view. However, in my experience with agile development I have not seen a de-emphasis in the role of analyst. To the contrary, I've seen the expectations and demands on people in that role broaden.

If it were ever really true that business people and technologists could not communicate directly with one another, it is certainly not true today. I'm not sure how we ever came to believe it in the first place, but we must have believed it since we allowed a whole profession to grow up in between stakeholders and development teams. I think that's a structural problem in conventional organizations.

I may be mis-reading you, but it seems as if you advocate reinforcing the separation between stakeholders and development teams by deepening the administrative layer that separates the two in conventional organizations - the business analysts. Wouldn't that make it harder to correct the structural problem - the separation itself? We don't need a "better liaison" between stakeholders and teams; we need to eliminate the barriers between them so that no liaison is needed (or perceived to be needed) at all. We need to facilitate direct collaboration among all parties involved in a project, to the extent that is feasible in each case.

The most effective agile projects I've been involved with have been characterized by teams that included all necessary skillsets and that were collocated with the key user groups or stakeholders for the application under development. The teams did not work at a fixed location, but were temporarily located at the offices of their customers. Of course I've been involved with many projects that were not physically organized in that way and that were able to apply some agile methods effectively, but they were less effective than the projects that were able to have everyone working directly together.

When it is feasible for everyone to collaborate directly, then the need for a "liaison" evaporates. That does not imply the analyst is no longer needed. Instead, he/she must expand his/her skillset to include techniques such as executable requirements and direct support for acceptance testing. This is a far more useful role than the traditional one of "liaison," and it is a more demanding role, as well. Far from de-emphasizing the role, agile methods (when they are really applied and not merely talked-about, that is) actually ask more of business analysts than previous methods.

closing the chasm by Masa Maeda

It is true that Agile brings customers and dev teams closer than traditional approaches do. However, often times this is not entirely true as the size of the project increases. Small projects involve a very small number of customers (one or two) but mid and large size projects involve more customers with somewhat different requirements, and they might not have the experience or time to get their act together and some up with a coherent set of requirement. The BA becomes useful then, shaping up realistic, achievable requirements that satisfy the customers' needs and keeping them and the dev team on the same page.

The Role of the Analyst in Agile Projects by Sebastian Kübeck

In an Agile team, the analysts are part of the customer team among other members helping other members and developers to understand the domain and business demands. They can also assist in filling and prioritizing the product backlog. The difference between the waterfall analyst and the agile analyst is that the latter doesn't write huge specification documents that nobody reads in the end. Instead, he coaches the customer team and the developers.

Alan Cooper gave a great talk recently at the Agile 2008 conference wherein he spoke with passion about the need for inclusion of Interaction Design in Agile projects, someone who understands how people behave and who can help the Customer come up with guidelines for the technology implementation to ensure that the resultant product works effectively in real-world use.

My contention is that this role is one which is ideally and effectively undertaken by the Business Analyst

Wrong! The analyst is not replacing the interaction designer. She does not have the skills to do that (read Alan's Books to understand that)! She is coaching the interaction designer in understanding specific domain issues.

Who identifies the fact that there are (say) 1500 people who are currently doing their jobs in one way, and that after we've implemented the new software will need to significantly change their work patterns?

To change software and processes at the same time is a one way trip to project crash! That's the place where an experienced analyst can be extremely valuable to identify and stop that early enough. However, Agile processes are self correcting. Users will reject changes that push them in the wrong direction.

We all are BAs! by JM Beas

Maybe I am oversimplifying the issue, but IMO what Agile methodologies (like Scrum) empower is the democratization of speciallist roles, like architects or BAs. Somehow, all of the members of the team become a BA because everyone is encouraged to get involved in the user stories like users do, through communication and a closer work among them.

It depends by James King

I think the democratic view that we are all BAs ... and testers ... and developers works well for a small team that stays together and specialises in the one product.

But I think this approach only works with small teams, who are co-located and who either know the customer crew or are building a brand new product based on their own shared vision.

While this is the perfect set up for an Agile project, it is often not the case. So with a larger team, or a team that is part of a large corporate "ecosystem" the approach starts to become strained.

In those situations, "real" or specifically trained BAs are needed. These guys have the attitude and training to be better at the role of BA.

In a similar way, when I used to be a Unix administrator, I used to do "programming". But as the scale of the application grows I would rather have specialist developers who know Ruby on Rails really well (for example) rather than a good unix guy playing with Perl to see if he can build whats needed.

The problem behind the problem: What do they really want or need? by Brian Cook

Analysts should be experts in facilitation and coaching on techniques to bring clarity to and build consensus within the project team. Some of the comments posted have an assumption that customers know what they want or need. Unfortunately, I have not found this assumption to be true.

A related false assumption is that people can tell us what they know - accurately, completely and unambiguously. Who can describe something done regularly, like driving a car, and meet these criteria? We "know" how to do it. However, we cannot describe it. It gets much worse if we want to drive a new kind of car.

Rather, defining requirements or desired solutions is analogous to defining "good art". No one can tell you what good art is, but everyone knows it when they see it!

I have come to the conclusion that part of the problem is that we are using the wrong medium to describe requirements and solutions. If you were in the market for a new home, would you buy one from a textual description of it? How about from architectural drawings?

No. You want a life size model you can walk through to experience what this home is really like to discover if it will meet your needs. Yet we expect customers to tell us exactly what they want, not for a static house, but for dynamic applications with very complex behavior from text and/or architectural drawings. For further discussion of this topic see Using the Right Medium for System Requirements Gets Buy In.

As Shane said in the article:
“The traditional analysis "what before how" approach doesn't apply on Agile projects - most often we understand the "what" by showing the "how", in a productive and iterative cycle that is an inherent part of the Agile development process.

Look and Feel matters - the Agile Analyst helps bring this into sharp focus when the interaction aspects of the system are being worked on.”

Analysts should use every appropriate technique, technology and experience to help clarify team members’ perspectives and build consensus as early as possible in the project. It saves time and cost. The best way I know is to simulate the business processes and software solutions before coding begins. Simulation combines the “what” and the “how” in a visual medium that enables participation of a wider spectrum of people early in the project. The larger the group of people involved the more important clarity and consensus become. Analysts facilitate clarity and consensus on what they really want or need.

Look and feel does matter. To many users the UI is the application. There should be consensus on look and feel just like there should be for functionality.

Re: The problem behind the problem: What do they really want or need? by Brett Arthur

Another assumption is that business is simply going to accept and fund 'a good idea'. In my experience, business want to be convinced of the value and validity of the idea or opportunity upfront. The importance of the business case (that should be) the cornerstone to any new project, cannot be overlooked. The various options that may be available to business for solving a particular problem should be explored and a best-fit solution for the business in question should be recommended. This not only creates a situation where various possible options have been though through and qualified/disqualified with reasons, but can also be leveraged to guarantee early by-in from business.

Don't forget the 'agile' part of this by Tia Peterson

I find this conversation so fascinating. In my opinion, the ultimate goal is to build something timely that meets the customer's expectations and needs. Whether or not there is a business analyst active on the development team is a decision that needs to be left up to that team. If you fall into a prescriptive mentality about agile development, you've already lost and are no longer agile. You need to do what works for your team and the project at hand.

I disagree that we are all BAs and I strongly disagree with the notion that developers should practice business analysis. I would prefer to work with a developer who writes clean, working code in the best way she/he knows how to do. I want to work with a developer who focuses on the best WAY to accomplish the WHAT. The WHAT is my job. The WAY is the developer's job. Trying to master both of these things will extend the cycle and also, as a developer, I think you would be happier to not waste your time filtering through the mess of getting to the what, because, it's really messy.

I've worked as a BA on projects where the developers insisted on my presence. I suppose many of you have not had this happen, but in cases where you are a small dev shop and you are dealing with a large PMP client, you will benefit from having a BA take the reins - from them, really - so that you can manage scope more effectively.

Project managers manage "when." BAs manage "what." Developers manage "how." There will always be back and forth and everyone's input is certainly necessary but in the end, someone has to be on point for owning that part of it. That's been my experience. I know it's really oversimplifying it but keeping it simple rocks.

Thanks for the article!!

Context Knowledge by Kirk Fleming

Thought provoking ideas--very nice. I agree with the notion that a 'go-between' or 'liaison' or 'translator' can just add time, cost, complexity and, well, basically nothing positive to the communication between consumer and provider. But, that thought seems to be in a limited context--that of simply transforming one or more requirements (at the story level, for example) into an implemented solution. I also agree with the idea that there are 'what' and 'how' roles needed, and they don't necessarily optimize in the same people.

But, I see the BA function as huge in the areas of 'why' and 'at what impact'. So, in my experience, there's not always as much communication between organizations as we'd expect, let alone within a given organization. 'Business people' can and are as narrow-viewed as anyone else about what the business is up to, and may not be all that aware of other initiatives and the impact of theirs on others. This seems to be a good place for the business analyst to play--not to translate between business and IT, but to help ensure a more enterprise-wide, architectural perspective of the business. Likewise, a broad enterprise-wide view of what IT already has or is building would be useful. This suggests a role that is aware of a bigger picture, at a higher level, and with planned direction in mind.

That's not necessarily a BA as we know it, but it's also probably not a developer as we know it, either. Anyway, lots of good points on this issue.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

14 Discuss