Failure and the Agile solution

Failure.  Not a great word, and something that genuinely strikes fear in to people’s hearts.  Over the past few of months I have listened to a couple of podcasts that have offered differing views on failure.  This is a topic that has always been at the forefront of my mind, as I always wanted to be someone who was not afraid to fail.  Obviously no-one wants to fail, but if you have the concept ingrained in your psyche that failure is an acceptable part of success, then you are more likely to listen with an open mind and try new things.  But life and work is competitive, and human mentality leaves little room for failure.  I work for a consultancy where the Owners are working every day to win new projects.  Once the projects are won, they must in turn be successfully implemented.  The web application or web site must be completed on time, on budget and meet, if not exceed, the requirements.

So where can failure fit in to the software development process?

Before answering that I will quickly summarize the two podcasts that inspired this article and their differing points of view.

I.A. Podcast – Failure: The Foundation for Success

Jeff Parks interviewing Brad Nunnally

This podcast really emphasizes a need to embrace failure as part of a design and development process.  They cover three key parts to failure recognition:

1) The importance of retrospectives and documenting warning signs to learn from past mistakes.

2) Not to shy away from assigning blame and highlighting the success of others.

3) The importance of embracing failure and keeping an open mind, realizing that everyone makes mistakes

Through a combination of these ideas, Jeff and Brad believe the quality of your work will increase and you will garner more respect and a closer working relationship with your colleagues and customers. Furthermore, the very act of embracing failure will leave you more open-minded.

37 Signals Podcast – Jason Fried’s speech at BIG Omaha 2009

Jason Fried is someone I respect hugely.  He is an entrepreneur who brings a forceful clarity of vision and thought to his work.  His blog articles and podcast episodes are always thought-provoking and centered around forthright, positive action, and the distillation of problems in to simple concepts.  During this podcast he references a previous article he wrote on Signal vs. Noise titled Learning from failure is overrated, which takes a very different view of failure to Jeff Parks and Brad Nunnally.

Jason does not agree with a culture of celebrating failure that he thinks has developed over the last few years.  Critically, Jason’s view on this topic is from an entrepreneurial / business perspective, not a development team perspective, and from this vantage point he see’s embracing failure as absolutely the wrong approach.  If you are embracing failure then you are focusing on the wrong thing.  Jason says that you should focus on your successes predominantly.  If you tried 10 things and 8 failed, you should focus on the 2 successes and try to replicate that, rather than analyze and emphasize the failure.  He is not suggesting you ignore your failings, and obviously lessons should be learnt, but for progress to be made you need to be successful, so that should always be your focus.

So to go back to my earlier question, where does failure fit in to the development process?  Agile would be my answer.  The Agile process encapsulates many of the points highlighted by these two podcasts, and my own beliefs on failure, and enshrines it in a procedural guideline that failure will happen and is just part of the process.  The key tenets of this philosophy in relation to failure are captured in these points.

1) Iterations

The very reason for iterations is that there is an implicit understanding that the first time around not everything will be correct.  The best we can do is strive to complete a requirement as we understand it at this point in time.  At the end of the iteration it will be reviewed and tested as it will be a working piece of functionality.  Feedback will come from the customer and it is either signed off as done, or that changes need to be made, or new stories added to that theme.  There are no failures as such, just a cycle of build and review that will eventually result in the finished product.  This both embraces failure as part of the process but also focuses on the positives and what is right in that first release, and builds from there.

2) Iteration retrospectives

Iteration retrospectives are such an important part of the Agile process and yet one that does seem to overlooked at times.  We were guilty of this in one of our recent projects and I think we repeated mistakes as result.  A retrospective is where the cards need to be laid on the table and a open discussion needs to take place.  Each team member needs to be honest about what they did well and what they struggled with, whether that be a personal issue or one with another team member.  The failings of an Iteration are clear for people to see, but what is most important, is laying out a plan for how to mitigate these problems going forward.  Often you can do this by looking at what has worked well and using those lessons learnt.

See this great article on retrospectives also: http://www.agilegamedevelopment.com/2008/06/when-we-talk-about-agile-we-use-phrase.html

3) Team work

Brad Nunnally in the IA Podcast mentions the flat team structure of Agile projects as a negative when embracing failure because there is no one in a position of overall responsibility to make owning up to failures possible.  I believe this to be an issue with the team in which Brad is working rather than an issue with Agile teams.  Your team in an Agile project is a team of equals.  You should all be pulling in the same direction, and are responsible to yourself and each other to complete your tasks.  There is no wall over which you can throw work.  If work did not get done, whether it was your task or not, it is the teams failing, not the individuals.  Whoever was assigned responsibility for the task will have to be the one that announces the failure, in the daily stand-up or retrospective, but it is the team who bears the responsibility.  Everyone must rally round to dissect why the problem happened and how it can be addressed.  A failure occurs because it was not raised early enough, or it was not addressed when it was raised.  If the problem was never raised by an individual, that can be a case where individual failure has occurred, and is most likely a personal trait that needs to be worked on, such as talking up when you need help, something that can be difficult for some people to do.  Obviously this becomes more difficult if there are disinterested or unmotivated individuals on the team, and if that is the case then we are moving in to the area of HR rather than Agile self-organization.  Overall, working in a self-organizing, flat team of project oriented individuals, should result in a culture of union of purpose where failings are embraced by the team, along with the successes.

So shall I just go out a start screwing things up?

Well, yes and no.  I think there is value in both Jeff Parks/Brad Nunnally’s embracing of failure and Jason Fried’s embracing of success.  I think it is important to have a healthy fear of failure, so I do cringe when using the word “embrace”.  That is being a little too familiar and comfortable with that outcome.  Failure should, and always will be, a prickly and uncomfortable topic, and I don’t think that is a bad thing.  We do not want to fail, we want to succeed.  If you are too comfortable with failure, you may start to confuse progress with consistent failings.  Lets not forget, failure does have a consequence, whether that be a monetary loss, or a disgruntled customer.  Positive reinforcement is needed to make sure that what is working is captured and repeated, and demonstrable progress is occurring.  I think this quote from Fred Brooks (author of “The Mythical Man-Month“) in the most recent Wired (August 2010) says it well:

You learn more from failure than success. In failure you’re forced to find out what did not work. But in success you can believe everything you did was great, when in fact some parts may not have worked at all.  Failure forces you to face reality.

I like that last sentence, “Failure forces you to face reality.”  I absolutely agree, but the nature of reality is that we need to succeed or else we may not get another chance at failing!  So I would say, lets embrace our successes but make sure to face our failings head-on, taking positive action to ensure the same mistakes are not repeated.

Mind Maps – A Love Story

It’s a tacky title I know, but what is really tacky is that it’s true. Over the last few months I have used Mind Maps for such a wide variety of situations, that I thought it deserved its own blog post.

I have found Mind Maps to be an extremely versatile visualization technique, helping me capture and clarify information.  Through the presentation of disparate information objects on one screen, connections between those objects present themselves naturally. I have personally found it also promotes creative thinking.  Because the maps removes the notion of a list or paragraph of text, it instead encourages your brain to not only make connections, but also to think ahead, imagining new and different threads growing from the connected or unconnected objects.

Here are some examples of the scenarios when I have used Mind Maps.

Requirements meetings

This is a BA blog so requirements are the most natural place to start. I have used the Mind Map tool to capture notes in a meeting on requirements and have found it to be very effective. By creating a node for each requirement stemming from a central node of a theme or screen, the notes and comments build around the requirements nodes very naturally and you start to quickly see questions and dependencies between requirements.   Using the relationship arrows, references to previous points can be quickly made, and those relationships jump out at you because of the presentation style of your notes. Also little features such as adding Priority and Star icons let you markup your notes effectively so they can be efficiently acted upon later.

Brainstorming

This is the classic application of this tool. The quick way that nodes can be created, manipulated and connected is perfect for a session where you need to come up with a new idea or creatively work your way out of a situation or dead end. There is a throw-away and casual nature to recording information on a Mind Map.  It feels flexible and malleable, and more of a marker for further discussion. Noting down something on a list creates a more static representation of the information, and, to me anyway, constricts my thinking on topic.

Brainstorm

Workflows – States & Transitions

This was a surprising application of the tool, and I cannot take credit for it either. A colleague was trying to get his head around the workflow and accompanying states and transitions for a touch screen Silverlight application our team had developed.  There was a bug and it could not be nailed down and we needed some way of seeing the steps on the UI and the behind the scenes associations to methodically track down the problem.   Using the mind map tool, combining the structure templates provided to arrive at a fluid and effective visual representation of the workflow.  It was a more “folksy” or ad-hoc approach to a formal UML activity diagram in Visio, but was immediately understandable and allowed everyone on the team to contribute to solving the problem, whether they are tech minded or not. Since then I have used the same method for a Site Map that also showed a fields and associations. I plan to write another blog post on the discussion this raised for me about when to use formal diagramming techniques vs. whatever technique transmits the information most effectively to the average person.

States & Transitions

Problem Solving

Finally, I have used mind maps to flesh out ideas or to start solving problems that are rattling around inside my head. One of my idiosyncrasies is that I am a verbal problem solver, by saying something out loud I start to understand the problem better and so more often than not arrive a solution at that very point of verbalizing.  But for those times when talking out loud is not possible, I have used mind maps as a way to quickly right down the key ideas and connect and move them around, and the results have been very similar.  It gets those problems out of my head and allows easy manipulation which often allows the answer to present itself.

So what mind map tool(s) are you using I hear you cry? Well just one has been enough, and the good news is it is free!  Check out XMind (http://www.xmind.net/).

You can also try these options listed in the Wikipedia entry on Mind Map Software.

The Agile BA / PM – First Impressions

So I am 12 weeks in to my new role as an Agile Business Analyst, so I wanted to give a summary of my impressions, and how the role combines with being a Project Manager and QA part-timer.

1) Documentation

No more paperwork!

This is the biggest area of change for me, and from my perspective a welcome relief.  Gone are the bulky Business Requirements Documents that I slaved over for days, only for the customer not to read, and for the team not to look at again once the review is over.  Agile is agile because it is nimble.  You do not weigh yourself down with hefty tomes, documenting every in and out of the project.  Instead, stories, and scenarios are used.  Work is done firmly at the business level.  What does the business need?  Let the Technical Lead do the interpretation.  Yes you need to be grounded in technical reality when the implementation starts,  but you don’t know why you are doing it unless you have captured the business level goal.  This can normally be captured in a sentence, or short story, and the simpler the better.

2)  Requirements Gathering as a Conversation

Requirements are a continuous dialogue.

The convention of Agile requires that the customer be heavily involved in the project throughout the lifetime of development.  Although we cannot incorporate the customer to the level we would like, we are still delivering working functionality and demos every week or two, so a constant stream of feedback is available.  This dramatically changes the requirements gathering process.  Working from iteration to iteration, as the BA I work ahead of the developers as much as possible, reviewing the stories and clarifying requirements.  However more typically I am working in the moment with developers as requirements questions come up, because they don’t know the roadblocks or lack of understanding until they really get in to working on a story.  So on these occasions, we are having ad hoc meetings with the customer, discussing their needs and working through use cases, that will result in working functionality very quickly, typically no longer than 2 weeks.  The discussion therefore remains fresh in their mind, the decision is captured and implemented quickly, and the presentation of the result is fast.  I have found this to be a very effective way to seek requirements and verify their understanding.  Nothing is ever captured and documented, never to mentioned again until weeks or months later when the product is delivered.  This is why requirements gathering now feels like a real dialogue, a never ending conversation stream connecting the developers to the business, and vice-versa, through myself and the Tech Lead.

3) Project Management

Not Project Manager, Project Co-ordinator.

This is the completely new area for me as I have never been a Project Manager before.  However, once again, Agile to the rescue! The PM role in our Agile projects is very limited, and in fact we call it Project Co-ordinator to stay true to the team ethic of Agile.  We are all in it together and not under the instruction and watchful eye of a manager per se.  The small teams, and heavy involvement I have as the BA means that I have my finger on the pulse of the projects progress.  But more importantly, the iteration development cycle means that we are never falling behind schedule or stressing about keeping Microsoft Project up to date.  We assign stories to be completed in an iteration, based on the number of points we estimate can be completed.  One or two weeks later, we know if we have hit that or not, and we estimate the next iteration based on the last.  Apart from that, I do some burn down charts, however not for all projects, it depends on the customer, as does whether they need some thorough updates as we progress, but really the PM responsibility is limited.  Most critically in this role I feel the need to stay Agile.  Don’t get bogged down in facts and figures and work that does not have business and customer value.  It is a powerful motivator to stay on track, and follow only those critical metric required for the project to succeed and to keep the customer happy.

4) QA as Usability Testing

What is the customer experience?

I have found this area to be the most challenging and perhaps, dare I say it, the least interesting part of the process.  It is a vital aspect to the process, no doubt, however my lack of training or formalized approach to this function means that I maybe create more work and more repetitive actions as I feel my way through the process.  However, I have found it is an excellent opportunity to do some rudimentary usability testing.  I put on my “I am the user or customer” hat and dig in to the fledgling software, asking the basic or simple questions of the developers to see if there is a better or simpler way to do things.  So it is not just Use Cases, bugs, issues, report, it is once again a more fluid dialogue of not only the issues found but maybe a better way to organize a screen or function during the next iteration.

Overall, I am thrilled with my new role. I am learning so much, and I am involved in so many things that I have wanted to be doing for so long now.  I will try and keep the articles coming as I truly define my place as a Business Analyst / Project Manager in the Agile software development world.

Thanks again for reading!

The Business Analyst and Knowledge Management

Knowledge is valuable

I have read a few articles recently that have talked about the promotion potential of Business Analyst’s, particularly at Laura Brandenburg’s excellent http://www.bridging-the-gap.com.  What jobs are open to a BA? What skills do you have that can open new avenues?  I think this is a very valid discussion as the BA role can seem pretty flat in terms of long-term potential.  What is the career path? Senior Business Analyst? Super Senior Business Analyst?

There are typical answers to this, the most common being Project Manager, but that is one that I find distinctly unappealing.  I think being an Analyst means you are the type of person who likes to get in to the weeds of a project a little too much for you to transfer nicely to a PM role.  In a previous post I spoke about the cross-over between a BA and an Information Architect, and I still believe this is an open avenue, but this may be too “webby” or design focused a step for some people, as well as being a rare field, still growing and maturing and hence difficult to access.

As part of my Masters in Business & Information Technology at DePaul, I am taking a course in Knowledge Management, and it is fascinating.  It is such a fuzzy area and almost a non-subject according to some, however I see a lot of value in it.  It centers around not only how do we collate what we know in to knowledge bases but also how do we identify, stimulate and capture this information from experts within the organization.

Something that seems very clear to me is how a Business Analyst can significantly help in this area, if they have worked within an organization for a period of time.  Over the course of various projects, many interviews have been conducted, problem domains examined and modeled, and a sense of the organizations knowledge centers would have been subconsciously formed.  As the BA who is observing and objectively analyzing how information, data and processes flow within a company, they are essentially tracking the knowledge flow through a company, how it is formed and who are the creators, experts, team players etc. who contribute to it’s formation.

So when you are next creating an Activity Model, or interviewing key stakeholders for a new system, keep in mind that you are also tapping in to a key knowledge resource, that has a broader importance.  If there is a knowledge management initiative at your company you may then be able to leverage this information outside of the main project focus.  But if there isn’t a knowledge management initiative, then maybe this is a good way to propose one and perhaps land yourself with a Knowledge Management project.

Related posts on the Business Analyst career path:

http://www.bridging-the-gap.com/can-i-be-promoted-as-a-business-analyst/

http://www.bridging-the-gap.com/whats-next-what-do-i-do-after-im-done-being-a-business-analyst/

http://www.businessanalyst.com/advance-from-business-analyst-to-business-architect/

The BA and Expectation Setting

The expectation gap

Expectations can destroy a project.  If the stakeholders have inflated, unrealistic expectations, regardless of the projects final deliverable, it will be classified as a failure.  The stakeholders will be disappointed and the project team will be demoralized.  The BA must play the role of project realist and ground the stakeholders, tethering them to the true idea of what the final deliverable will be.  The BA is uniquely positioned to fulfill this “Expectation Enforcer” role because of their requirements gathering responsibilities.

In my current BA role implementing a SaaS product, this is particularly critical.  I am the face of the company and product following the successful sales cycle, where they have been courted and wooed with the promises of time and cost savings and a great user experience.  During the 2-day requirements gathering meeting which follows the sales to implementation hand-off, one of the big parts of my job is not just gathering functional requirements and building the stakeholder relationship, but also gradually and carefully grounding those expectations which are often floating in the stratosphere.

This is a very tricky, balancing act that requires the BA to use all the soft skills they have at their disposal.  The customer’s enthusiasm and eagerness needs to be maintained and nurtured. Kill that now and you set up a long and difficult road for the project.  But let them run free and unchecked and you have a bigger problem and will set up the project to fail.

Expectation setting must not mean be negative.  The chips and knocks to their ideal of the project must happen organically and naturally as the conversation develops and the requirements are gathered.  It is because of this that I feel the BA is perfectly suited to the “Expectation Enforcer”.

With each requirement elicited comes the opportunity to gauge what the customer is expecting.

 

The BA must address each and every one of these expectations.  Probing, questioning, and resetting the scene to approach the problem from a new perspective, just as you would for a functional requirement.  As this discussion progresses you must latch on to what to what is possible, and enthusiastically confirm that assertion.  As we all know, start with a positive before delivering less favorable news.  Then carefully bring the customer down out of the cloud, ensuring they understand the realities of the project.  Whether that be the customization limitations of an existing SaaS product, or the constraints of a new development project, where cost, time or scope may mean their expectation cannot be met.

As is so often the case, using visuals greatly assists the process.  Working with a SaaS product, I use the requirements meeting to run demos in a test database, and show exactly what it is they are getting at every turn.  This works really well at transferring the enthusiasm from the ideal in their head, to how it will actually look and work.

Often the functionality is as they expected, it just works in a different way to the mental model they had developed during the sales cycle.

If working on a new development project, the principles of Agile and User Centered Design will play a big part in reigning in the expectations also.  Delivering working products quickly, soliciting constant stakeholder feedback, testing and iterating, will make sure that the customer understands quickly the realities of the project.  If you are working on a waterfall project (I feel for you), showing prototypes and using whatever visuals you have to hand as the project develops will help fend off the “this isn’t what we expected” comment when the product is delivered.

I would love to hear other BA’s opinions on this topic, particularly those working on new development projects, and how you approach this critical issue.

Thanks as always for reading.

Agile and User Centered Design

Nielsen Norman Group

This new article from Jakob Nielsen was an interesting read. It relates back, in a roundabout way if you really squint at it from a distance, to my previous posts (here and here) on where the Business Analyst fits in to the User Centered Design (UCD) process. Nielsen is looking at the problem from the perspective of how UCD fits in to the Agile development lifecycle. The focus on a rapid sprint style of development leaves little room for user engagement and testing. Furthermore the concentration on small sprints to achieve functionality can be at the expense of a unified, user-focused design and information architecture. Unless of course that UCD is integrated in to the project from the beginning. This is Nielsen’s point.

The BA gets involved in many of the areas that UCD preaches (requirements gathering, wireframing, information structure, process flow etc.) but he/she is not a designer, so my query was how they fit together? Nielsen makes this comment:

“it’s important to designate a gatekeeper to track requirements and communications between the UX team and the other project teams to keep everybody on track (even though those tracks are parallel).”

This would be a natural starting point for a BA to again be that bridge between two groups. Although it sounds like a Project Manager type role at first glance, I see greater scope for engagement and influence in the project, and so more of a BA type role. To be the “gatekeeper” between the UCD team and the development team. To integrate the user and design requirements from the UCD side, and working within the information architecture and design principals, bringing that to bear on the functional requirements and delivering that to the development team.

Just a thought.

Does the BA look at the user experience?

A paper website prototype

Just a quick follow up to my last post which aimed to gather comments clarifying a couple of points.  What are the key functional differences between the BA and Information Architect (IA) roles, and how the split falls between requirements gathering and user centered design (UCD).

I am an avid listener to the Spoolcast podcast from User Interface Enginerring (UIE).  It is really informative and Jared Spool always has some great guests discussing UCD and UX topics. One of the recent guests, Todd Zaki Warfel, was talking about prototyping experiences, and during this discussion he touched on the very same role definition issue. Jared at one point posed the question to Todd, does the BA in even look at the user experience? This brought up some interesting points I wanted to share.

Todd felt that the BA’s typical remit on a project was functionality.  What functional requirements does the product need to fulfil.  So although the BA is involved in the design of prototypes, he saw these as being on the wireframe, boxes and arrows, Visio end of the spectrum. A prototype designed to show that the functional requirements elicited from the users and stakeholders will be met, and visually how those functions will look, in their rawest form.

However an Information Architect or User Interface Designer will approach building the prototype by trying to take it that much closer to the final look and feel of the site will be.  Again the functionality will be there, but there would be more care and attention to the usability and user experience with the site.  He also felt that the designer would be more willing to take a risk and create something very new, whereas the BA may be more inclined to stick to existing structures.  He used the specific example of the designer adding AJAX type aspects to their prototypes.

I certainly think that makes sense and although every BA and IA role will vary from company to company and project to project, I can see this line holding true the majority of times.  It does also back up my contention that in fact there is a fine line between the BA role and the UCD process and that the two sides could easily be joined if necessary.  This provides excellent room for growth in a BA’s armory if they can bring in valuable usability and user design techniques and perspectives to the requirement’s gathering remit. Particularly when expressing those requirements visually, which always seems to be the best way to really engage the stakeholders in the requirement’s process as they start to see the result to all the questioning.

Business Analyst or Information Architect?

Information Architect or Business Analyst? Which way to go?

This post from Paul Culmsee at Cleverworkarounds.com tapped in to something that has rattled around my head for a while.   My career aim is to work as a Business Analyst in software development.  I pursued this role whilst still in my old career as I understood that the BA role most closely fulfilled the idea I had of being a bridge between the business and technology.  Not that being the business-IT bridge was an original idea, but it was the basis from which my new career direction has sprung.  As my knowledge has grown and I have moved in to a semi-BA role (I say semi because half of my role falls under customer service and training), my horizons are expanding and so has my confusion about where the BA fits in to a project and the role they play. It seems the simple answer is that the BA role is however that particular company, or project, defines it.  There are common threads of course, the requirements gathering function being the key one, but other tasks and responsibilities float around the position, liable to be cherry picked from organization to organization, project to project.  These include PM responsibilities, testing, product strategy and many more.  The question I am throwing out to the blogging ether is does it stretch in to the usability and information architecture realm also?

For lack of a better description, this last month I have been gripped, reading and learning about usability, user centered design, user experience and information architecture.  As mentioned before, my Interaction Design course at DePaul has really kickstarted this frenzy, but also in working with my friend at Booyant.com, and some possible usability testing and website analytics work I will be doing for them.  I think the user focussed and user centered design (UCD) methods are intriguing and certainly something I would like to get involved with.   But how do Business Analysts fit in with these methods and roles?

The main reason I ask is that Requirements Gathering is a key part of UCD, as it is for BA’s, so are there BA’s out there who are usability specialist BA’s?  Or does the requirements gathering neatly split between user requirements to the usability specialist and the business requirements to the BA?  I see how that may be possible with a consumer/public facing product but when the software is for internal use, the user is the business. Who takes the requirements then?  It also seems that the usability focused requirements gatherer takes those ideas further down the design path, creating conceptual designs and wireframes to encapsulate the requirements, rather than the BA method of perhaps mapping data flow, artifacts or business processes and documenting the requirements in a traditional style.  However use cases and stories are used on both sides……

Lets just say I am a little confused.

Which moves me on to the Information Architect role.  The idea of this position seems perfect based on my interests.  From the outside looking in, I see the role like the usability focussed BA .  It does not fall directly under the creative or graphic design umbrella of software development, so I do not need engage my non-existent artistic side, but looks instead at getting more involved in the layout and structure of the site, mapping the user requirements to software functionality.  In that way it seems like a more fulfilling, engaging and strategic position that enables you to put in to action the requirements gathering and understanding work you have done, and structuring the sites information. I particularly like this quote from The Information Architecture Institute(IAI) website:

Jeffrey Veen, Adaptive Path and author, The Art And Science Of Web Design
“I’ve found information architecture serves business as a development process as much as a discipline for structuring content. IA demands a clear understanding of how content can connect customer goals with business objectives. And regardless of medium, that’s the definition of success.”

I love this idea, but as I said I am on the outside looking in, and as Paul Culmsee’s post says, the name of a role can be little more than group of people getting together and forming a club.  So is what I described anywhere close to what an Information Architect does?

My research will continue, the Information Architecture book from Louis Rosenfeld and Peter Morville seems like a good place to start and there is a good reading list on the IAI website, but any suggestions and input will be gladly accepted.

Help me if you can.

Thanks for reading.

Why business analysis?

I just read this article in Wired (love that magazine) and it got me all jazzed up and for a few minutes I couldn’t understand why. But then it dawned on me, it taps in to the very reason I sought out the role of Business Analyst even before I knew the role existed.

The article talks about the internet revolution resulting in a “good enuf” or lo-fi mentality. In particular it sites the MP3 revolution of the music industry. Music insiders scoffed at the thought of a lower grade music format when the whole industry had been striving for excellence in this area and was happily wallowing in the superiority of CD quality sound over vinyl. But the MP3 music file turned everything on its head. It tapped into an unknown or at least overlooked critical requirement of the music consumer. Shareability. All of sudden these inferior files were changing the face of music. One of the company’s that first realized this ground shift in user requirements was Apple and I can certainly argue that the very reason I am able to type this blog on my iPhone is because of the success of Apples MP3 business, iTunes and iPod.

This is what fascinates me about the BA role and why it is so important. Without a business focussed technology advocate committed to probing for user requirements the product can just end up being the baby of one of the internal groups, the developers, the designers/marketing or the business. Either way the most important group has been missed, the user. So unless you have someone pushing and asking the right questions you may just be missing an MP3/iPod type game changing product. That is what excites me about the BA role and why I think it is such a fascinating area, especially Agile methodologies and user centered design which I am learning more about now and will blog about soon.

The BA Role, Testing and Support

So this has been a very slow start to my blogging life, I realize this, but essentially since I first got my new job and have subsequently started, really not a whole lot has been happening to blog about. I have just completed my 11 weeks of training with the 15 other new new-hires which has been a mix of methodology and industry training (of which there was a lot to cover).

What is clear however is this company has a very structured and well documented (oh my god the amount of documentation, the intranet is huge!!) approach to the implementation of their software. My role, as it turns out, is actually a combined role of Business Analyst and Customer Support (CS). So I do go in and gather all of the requirements for the software implementation and create a Business Requirements Document from which to work, but instead of passing this client relationship and knowledge on to the CS as it was historically done, I will now also see the client through the test and audit phase after the software has been loaded with the data, help them understand the reports the software generates and will be on-site for when the software goes live.

So I understand that this is not a 100% business analyst role, not that there is really a clear standard for that role anyway as every company seems to use the title and role differently, but it did get me thinking over what percentage of typical Business Analyst’s actually do work on their projects through testing and go-live in the same way?

It seems to me that if you are in a consultancy specializing in Agile software development or as a freelance business requirements gatherer then the answer is probably very little. You have a specific job that you are called in for and any additional involvement is not so explicit. But if you are working in the belly of the corporate beast as I am, then your role probably does have a more holistic aspect where you are seeing projects through to conclusion.

At this point what this actually means for my job is completely unclear as I haven’t even started working on an account. However at this juncture I am looking forward to being able to see my clients through to go live as I feel it will give me a good sense of achievement to actually see the results of the earlier requirements gathering work. I also foresee an excellent learning opportunity because only when the software is up and running and being used by the clients users can you really see how it is used in real life, and where you may have made some errors in the BRD and set-up.

There is an article on the Business Analysis Times that discusses this area – http://www.batimes.com/index.php?option=com_content&task=view&id=248&Itemid=1. I also stumbled across a posting on this on the Requirements Networking Group website (http://www.requirementsnetwork.com/node/1199) however this is in direct relation to Agile and SCRUM development of which I have no knowledge at this point.

If anyone has any input on what happens in your role in relation to testing I would be very interested to hear.