Check out Warren’s presentation in the recorded video of the webinar. He is the 3^rd presenter. You may also want to access a PDF of the webinar inside the IIBA’s public webinar archive.

Starting off by defining what Business Analysis Practice Management means, and emphasising how important it is, we explore the types of agile tools that are out there for BAs, how The BA Kit works in parallel with those tools, and helps introduce some consistency into when other tools are used, by whom, and how well. The BA Kit can be considered theone source of truth for all the flavours of agile and non-agile methodologies and BA tasks.

We then presented a subjective graph (based on our experience and evaluations) that shows that there is a gap between what the evolving agile-specific tools offer, and the TOTALrole and actions of a BA. The BA Kit fulfils some of this gap, especially in planning and monitoring area, but across all body of knowledge areas.

A BA’s level of engagement on a project can fall into seven decreasing levels of involvement, and you may need a tool (such as The BA Kit) to cater for that variety that can eventuate in an individual agile project. We use the concept of a ‘stencil’ in The BA Kit to change-up the methodology being employed for a specific project depending on the level of specialist BA engagement in the agile project, as dictated by the business/product owner.

Agile projects tend to have a number of continuums that require balancing so that the role of the BA is clear and ratified. An Agile project team may contain a group of agile practitioners who are multi-skilled generalists (who can cover analysis, development and have the business product knowledge), or perhaps the Agile project team has more specialised roles, where a skilled BA is differentiated from other team members.

Natural tensions will exist for a BA who is both part of an Agile project team and also part of a pool of BA resources in an established practice inside an organisation. Regardless, the Product Owner in an Agile team and the BA Practice Manager will both require visibility of what activities the BA has been carrying out, to which time frames, and to what level of success.

The BA Kit facilitates the setting up of consistent processes and tasks for the BA to carry out, and then lets the Product Owner, Project Manager and BA Manager track and monitor progress in near real-time. The BA Kit caters for both ‘masters’ in managing the value of the BA.

Importantly, you don’t need to have separate systems for Agile and for non-Agile in terms of practice management if you are using The BA Kit, as a key is ‘flexibility’. You can start from scratch and create your own groupings of agile tasks, and create your own templates and details . . . or you can grab our inbuilt agile methodology and use that, including our take on what templates and worked examples will be of use . . . or you can do a bit of both – make a copy of our inbuilt methodology, change things, add new tasks, or perhaps even drag in a few other tasks from non-agile methodologies to make a hybrid. Maybe the governance on your projects requires typical waterfall-based business case planning, or the mandatory inclusion of use-cases for example.

Check out the 3^rd presentation inside the webinar and see what you think. We are keen to get your thoughts!

Despite the rapid growth in both the government and private sectors, I consider business analysis practice maturity to still be in its infancy and that there are few organisations in New Zealand that can lay claim to having achieved the ‘holy grail’ of a fully functioning Business Analysis Centre of Excellence (BACoE).  I liken the establishment of a BACoE to “Reaching for the Stars”. If, in your lifetime, you’re fortunate to have the opportunity to “Reach for the Stars” then please embrace the faith that someone has placed in you and absolutely go for it. If the BACoE is not quite within your reach, relax, there is hope. “Settling for the Moon” (establishing a mature Business Analysis Practice) is not necessarily a bad option (in fact I think it comes a close second), can be a lot of fun and if done well, hugely satisfying for all involved.

Attempting to define a BACoE without taking over the whole blog requires discipline, especially on my part. Given I appreciate the simple things done well, I gravitated to this definition:

A BACoE is a team of people that is established to promote collaboration and the application of best practices. There are 3 key characteristics of a BACoE that have a significant impact on its value and operation, these being its authority, role, and organisation placement/staffing within the organisation.

Whilst the idea might have popped up over-night, good BACoE’s don’t. Like any significant change effort, an effective team is needed to drive, develop and maintain a BACoE. To avoid frustration, disappointment and ultimately tears, a BACoE requires executive sponsorship, commitment, investment, good planning and execution, a champion to lead this effort and more often than not, a company culture that encourages want to be the best and embraces continuous improvement.  For me, a real point of differentiation between a BACoE and a good BA Practice is that a BACoE (or CoE) has an enterprise-wide flavour. By this, I mean an enterprise focus to business issues, e.g. alignment with the project management group, enterprise architecture, data integration, business and IT optimisation, and enterprise-wide access to information. A good Business Analysis Practice has a more local flavour, with the focus on developing a good Business Analysis framework and works lives by a simple idea – focus on the best and neglect all the rest. Whilst you never turn down executive sponsorship, support and investment if offered, you can achieve a good Business Analysis Practice by unleashing the talent that already exists in your BA team, getting comfortable with the idea of being a leader without a title, and allocating the team responsibility for making a positive difference whilst creating a work environment which make it easy for to get up in the morning and come to work.

It’s also of the view that before we even contemplate achieving Business Analysis nirvana (BACoE) we need to have first got our house in order and have established a good  Business Analysis Practice – the building blocks for a BACoE. If we are not afraid to be honest with ourselves and ask the hard questions (which we are trained to do), for many, a good business analyst practice will be all that is needed, all that is required and more importantly, will be a realistic and achievable goal that doesn’t kill the team in the process.

So which journey is the right one for you? The journey is likely to hurl you into the great unknown at warp speed but it will force you to embark on a serious of soul searching questions about yourself, your environment and your organisation which can only be good on all levels…right? I will cover this off in the following blogs but to help you get started, please consider the following four things you need to come to grips with and, may  ultimately help with the decision making process.

• What are the characteristics of your current business analysis workforce?
• What kind of business analysis workforce do you need?
• What is needed to build a mature analysis practice?
• How are you going to get there?

When coming to grips with these questions, the worst thing you can do is…..put them in the too hard basket and do nothing. According to the Forrester/IIBA September 2010 Global Business Analyst Online Survey, 28% of BAs responded have already made the decision, are involved in initiatives for creating a business analysis or requirements centre of excellence. This indicates that organisations are focusing more attention on business analysis skills and practices. I’ve also seen an emergence of organisations creating communities of practice, by this, bringing BAs together to share good practices, processes, templates, ideas and lessons learned (good BA Practice). Whilst you might have stakeholders that could benefit from understanding (at a high level) requirements management. Your executives might not care about repeatable processes, re-use, BABOK or the nitty-gritty details of functional (and non-functional) requirements, they all care about is delivering what was promised on time. This is requirements management,  it’s our zone and is why we should all care about “Reaching for the Stars” or Settling for the Moon”

In my next blog posting, I’ll dive deeper and share ideas for boldly going where others have already gone before. But for now, have fun, go wild and always remember “discipline at the core, creativity at the edge”.

Well, how often does one end up buying a car because a salesperson made a fabulous pitch? Never, or perhaps rare. Customers are growing smart enough to see beyond the impressive speech to check if they are buying a lemon.

Are we not told that in the mother of all metrics is how happy a customer is? But how often have we seen weekly status reports that end up looking like this?

Week 1 2 3 4 …after some weeks…Week n

So, what is the alternative to the soft-core business analysis approach?It’s time to define success of business analysis by intelligent metrics than rely on the emotional state of fickle customers. The blog proposes few metrics under four different categories that could help chart the health status of business analysis.

Requirements Elicitation Metrics

Requirements discovery rate: Number of new requirements (scenarios, processes, rules, use cases) elicited with stakeholders over a period of time. (say reporting time of a week)

Value of discovered requirements: What is the total business value of requirements discovered?

Priority of discovered requirements:  Is there a consensus of requirements priority and focus given to high priority requirements?

Pending scope issues: Number of scope issues pending at the end of requirements elicitation cycle.

Requirements Analysis Metrics

Requirements velocity: What is the time taken for requirements to move from draft to review and review to approved?

Requirements churn: How often does the requirements change before moving from draft to review status? (this could indicate requirements are unstable)

Traceability metrics:  A summary of traced and untraced requirements to scope and business drivers.

Requirements Quality: Metrics from requirements reviews including missed requirements, ambiguous requirements, incomplete requirements.

Requirements Management Metrics

Requirements change: Number of requirements change requests after the baselining of requirements was complete

Review process metrics: Number of review cycles, stakeholder response time, approvals received from stakeholders, response time to requirements reviews, root cause analysis of requirements defects.

Requirements plan metrics: Planned against actuals for requirements schedule, effort and resource, # of times requirements plan was changed, root cause analysis of plan changes.

Requirements management metrics: Issues identified and resolved, risks mitigated and requirements sizing in terms of Function Points, value analysis etc.

Stakeholder Metrics

Stakeholder analysis metrics: Number of stakeholders identified, stakeholders missed and churn in stakeholder analysis

Stakeholder availability metrics: Delays due to non-availability of stakeholders to requirements elicitation, requirements review and validation; average response time to review cycles and requirements clarification.

Stakeholder satisfaction metrics: Feedback survey of all stakeholders at the end (and possibly once in between in case of a large project) with metrics to measure intangibles such as leadership, innovation, risk management, process management, expectation and satisfaction etc.

The purpose of this blog is not to enumerate all possible metrics, but to highlight key numbers that would provide a glimpse into the state of business analysis activity in a project. Analysis is a primarily an engineering activity and requires quantitative approach to  manage and improve the process.

While the above numbers might look daunting to collect, it is quite easy to gather these numbers from a good requirements management tool. Modern requirements management tools are capable of generating excellent meta-data that provide excellent insight into evolution of requirements.

The above requirements metrics maps out the DNA of your business analysis practice. Unravel the world of business analysis … with numbers!

We’ve snuck in a few cool features too – as your business analysis partners, we wanted a dedicated area for useful bits and pieces for all business analysts – see for the BA. And if you want to see how we’ve evolved and some of our key achievements, we’ve got a nifty timeline so you can see what we’ve done at a glance. The revamp has been a great opportunity to showcase our software product The BA Kit, and some of our new service offerings – BA Capability Assessments and BA Maturity Assessments.

As well as better explaining what we do, we wanted to show you who does it! So, in the name of bringing our People to the People, here’s a quick rundown of who does what. And for those visitors who aren’t 100% sure of whether they actually need a BA – here’s all you need to know.

We were keen to make the site more relevant for potential employees too, so if you’re an ace BA looking to spread your wings, let us talk you through our job process. The website now gives you a better feel for the type of company we are and the way we value our staff.

We’d love to hear your thoughts – let us know if we’ve hit the mark, or if we need to make a few tweaks.

Cheers

Richard & Sarah Gibson
Redvespa Directors

Business Architecture Capability

One of the key drivers for the transformation of a business analyst to a business architect is the appropriate skill portfolio required to deliver in the strategic level.

Assessment of products, markets, services, operations and organization structure requires a strong understanding of the business domain. It is this ability to leverage management skills for a particular business domain to deliver a business value that makes a good business architect.
While information modeling and business intelligence analysis is embedded in the realm of IT, the ability to understand the lifecycle of the product, market characteristics and competitor positioning require understanding beyond IT.

While soft skills (communication, negotiation and interpersonal) are essential, management tools and techniques are critical to deliver business value. Skills assessment and identifying the roadmap for acquiring enterprise analysis skills is a key enabler for transformation.

Business Architecture Organization

Is the organization structured to leverage BA competency at the enterprise level? Questions that need to be considered in order to contribute at the strategic level are:

1. Where is the BA capability housed in the organization? Is it embedded in the business organization, independent or part of the IT solution space? For an Enterprise Business Analysis capability the BA organization should at least be independent, if not embedded with the business units.
2. Who is the BA accountable to? Are they responsible to business stakeholders and tied to business outcomes? Are BAs engaged in determining the feasibility, prioritization and commencement of decisions to achieve business outcomes?
3. Does the Business Analyst capability participate and receive early communication regarding the business scorecards, KPIs – strategic information to plan and develop enterprise solutions?

Business Architecture Methodology

Process plays a critical component in establishing and nurturing the enterprise analysis capability. Establishing pre-requisites such as having an approved business case prior to a program kick off will necessitate conditions for mandatory enterprise analysis.

Tools to support decision analysis, capability assessments, gap analysis will vastly improve productivity and efficiency. Business Architecture practice requires visibility and support from executive and senior operations team in business. Developing and managing critical knowledge (value chains, business KPIs, scorecards, competitor analysis) and leveraging the same for informed business decisions will provide avenues of strategic engagement with business.

In conclusion, the transformation from a project BA to an enterprise BA requires enablers to move beyond engineering to business management. Enablers, in the domain of people, process and organization structure facilitates the development of this green-field capability. Business Architecture practice is still a green-field domain and elaboration of these enablers and charting a transformation path is critical to shape this capability.

It was great to share Redvespa’s experience of working with the WCF web API – that’s the Windows Communication Foundation web API for those of you that haven’t come across this yet. The WCF web API lets you expose services, applications and data to the web directly over HTTP. The genuinely interested audience was a bonus.

At Redvespa, we’ve been using the WCF web API to create a layer on top of our existing application for The BA Kit, which exposes certain information over HTTP, because it’s a format that can be consumed by many different clients. Why? Well, the benefit for us is that it’s not platform specific – we don’t have to write a separate mobile application for Android, iOS, Blackberry, etc. We have used this API successfully with Sencha Touch (Mobile JavaScript Framework) – Sencha Touch can ask the API for whatever it needs, and both applications work seamlessly alongside each other.

We’d definitely recommend this approach for any developers experiencing similar issues in catering for so many mobile platforms. Check this link out for more details http://wcf.codeplex.com/documentation

For anyone wanting to keep across new technologies, the .NET meetups are an easy way to share ideas, and network with other developers using Microsoft .NET (especially if you work for a small company and don’t have the support of a large IT team). And for other female developers out there, step up and get involved – here’s an industry that we need to make our mark in.

Helpful? Let me know.

Cheers
Kai Shum
Developer

From time to time colleagues ask me, “When are you going to pull your finger out and get certified as a business analyst?” Bruce Melrose CBAP.  Well, as it stands, I’m not inclined to.

It’s not that I have anything against accreditation. I’m actually very supportive of accreditation and being a certified professional. It acknowledges analysis as a professional skill, and that has to be good.

The issue I have is a personal one. For me, while the ideal is good, the execution of the IIBA CBAP accreditation is really lousy. It just doesn’t work for me.

Everyone is different and like it or not, everyone comes from a different place and travels their own unique journey. It’s important to understand that. The good folks up in San Francisco (or wherever the IIBA is based) don’t. It’s the achilles heel of their framework. But it is – ironically – entirely practical.

For me, when I got into the IT industry and specifically analysis, I also undertook a BBS endorsed in Information Technology from Massey University. The course was a very practical and hands on one. I still remember (fondly, I think) the 2.01 analysis paper that was also known as the divorce paper. My lecturers indicated that to do the paper justice, you’d need to put in 100-hours over the semester. 500-hours more like! At the time I worked at a big Bank in the IT shop. I had a 2-year old daughter. After we put her to bed at 7pm, it was analysis study through to 3am and then up at 6am for a 7.30am start doing more of the same through to 5pm.

Over that semester the 2.01 paper, and others, had me create a dentists appointment system from requirements capture, analysis and modelling of those requirements, through to coding and implementation of the application.  That was defining. It was intended to assess the application of what we learned from the books. What the IIBA subsequently ask of me is not of the same standard. In fact, it does not reach a benchmark to really determine whether someone ought to be certified or not, to be frank. Rote learning of definitions, mnemonics and prompts simply doesn’t cut it. Not by a long shot.

Don’t get me wrong, I agree with setting a body of knowledge. I refer to it, and even use the BABOK terms. There’s no question that it’s a relevant reference, but nothing within it will make me a better BA because I see no practice element within it.

When I look at what I did in my university years by comparison and the next 16 years working extensively around New Zealand, Australia and the UK (on big and small, difficult and complex pieces of analysis), it was all about the practice and the execution; of the trialling by error, the soft skills, of understanding people, their motives, agendas, fears and the politics that shaped them.  Therefore, my engagement with them as an effective analyst is all about the things that you won’t get from the BABOK and can’t be tested within the current framework.  Yet, they are the very attributes that conclusively define the professionalism expected of a certified BA.

So here’s the thing for me. Anyone submitting an application with 2000 hours of continuous BA work, who work as a contractor or consultant will meet all those practical and professional attributes mentioned earlier.

In asking for the hours and experience, along with 2 referees to vouch for you, the IIBA know this too. So why not simply accredit those candidates when they read their application? Experience and constant engagement equals, if not surpasses, a successful certification exam from where I sit. Let’s face it, if you were no good as a contracting or consulting BA, you won’t be hired, you won’t be able to rack up 2000 hours and you won’t be able to meet the qualification criterion.

That said, it is also interesting to me that all those practical and professional experiences that shape the tailored approach and execution of a good analyst are also the most likely, if applied, to result in a wrong answer against the IIBA exam.

The thing to understand is that business analysis is so often not really about the substantive content or techniques employed within analysis for modelling ideas or concepts. Suggested approaches outlined within the BABOK can be easily taught. It’s the other stuff; personal attributes, empathy, listening, understanding problems; 80% of that stuff is the stuff that actually defines a good BA from an average one.

You can argue it’s all covered in the CBAP/BABOK framework, but seriously, how do you truly assess it in real terms when the framework is a multiple choice answer on a computer screen?

I guess for me, and because I am genuinely supportive of the idea of accredited professionals, I wonder if consideration of achievement and demonstration would be a more worthwhile assessment of an analyst’s true ability against an industry benchmark rather than an ability to rote learn and recite answers to questions designed more to trip you up on fine granular text book details of definitions and concepts.

Sorry I just fail to connect with that.

I acknowledge it would be tricky to assess practical application of specific areas of analysis given the sensitive nature of the work often undertaken. Nevertheless, where there is a will there will be a way and it’ll be a better assessment in determining if you are a master BA versed with practical achievement or someone who can remember rhymes.

But even if you don’t buy my argument, then the other thing that really rattles me is that even if I did pull my finger out and got certified, it’s only for a few years. I have to keep paying to be re-certified. Just because I accept a role for 3-years as a Business Change Manager, aren’t I still not be a certified BA? Have I suddenly lost all recollection of my past experiences, practical aptitude and achievements? Hardly.

* * * *

In case you are wondering, I have taken a IIBA study course to prep for the CBAP exam. Initial indications were that I’d possibly scrape a pass if I were lucky on the day. My problem, as mentioned, is that my extensive experiences indicate that the right answer for me and how I successfully do things, isn’t the answer on the IIBA score card on too many occasions. I’ve never completed the application nor ever sat the exam.

Instead I remain happily Bruce Melrose PBA (Practical Business Analyst). I’ll stick with that, I think, for now, or until something significantly changes to make me re-evaluate my thinking.

Just my personal view. If you are studying for IIBA exams, good luck, IWUW (I Want Unlimited Wine) sorry I meant I wish you well.

The other utterance I heard around the same time was that other promise; the concept of technology re-use!   What that boiled down to was the creation of repositories or libraries of code that could be used in software coding, cutting down the need to create systems from a standing start.

I have to say that in all the bespoke development that I’ve been part of and/or been exposed to, the concept of re-use has fallen waaaay short of what was envisioned. The original idea was that common functionality developed could be re-used thereby saving time and effort in the development and test arenas by not having to re-code aspects of functionality into business solutions.

Underpinning software re-use was the concept of design patterns. The sort of functionality that lent itself towards reusable code came down to print functionality and application sign-on functionality but even with that, there always seemed to be an argument from business stakeholders that their needs were truly unique and therefore re-use was not for them. Every bank, for example, seemed to have unique requirements for their bank accounts, and the use of them.

That said, on the whole, there were some advances within the coding arena at least, and there were many successes born out of re-useable coding; so that was one promise from object orientated analysis that got some traction; and in stark contrast to that other promise regarding the decline of paper.

But whatever happened to the notion of re-useable analysis? I mean, it does stand to reason that to have reusable code available from object repositories or libraries, there ought to have been a reusable foundation for that code.

Design patterns were definitely out there although rarely if ever used from my experience, so where were the reusable requirements? Personally I’ve never encountered true re-usable requirements that would align with associated design patterns that in turn would connect with reusable code.

What I have seen is people who have simply dug out old requirements papers, blown off the dust and said, “These are our requirements, let’s just go with these”. And that’s valid! Difference is that I’m suggesting something a little more than requirement statements amounting to “Any solution must allow a bank teller to open a bank account.” Or conversely, requirements expressed in such a way as to allude to a (known) solution (which is all too common). Either are too vague and/or too specific.

I’ve also seen too many consultants come into businesses; agenda in their back pocket with entire business models and processes expecting to simply plop them in wherever they lay their hat and expect them to work (but of course they don’t). Isn’t that re-use? “Why doesn’t that work?” They lament. “This re-use  thing is a fallacy!” My observations tell me they didn’t recognise, or have lost sight of the likelihood of entire models and processes being reusable. It’s the more specific elements and sub-components within them including more specific requirement kernels that lend themselves to be re-used in different environments.

I recall mentioning this to a colleague of mine and the conversation turned rapidly into a “why would you be motivated to try and develop re-usable pieces of analysis?” All that would do is cut short your assignment and cost you or your employer money. I understand that view but I see things differently.

The motivation for this thinking was to be able to turn around a set of detailed core requirements more quickly with the benefit of then being able to concentrate only on the really specific requirements for a business. That is where the real focus of the engagement should be. That’s moving towards a smarter way of working and getting to the important stuff much quicker.

Under a happy day scenario, it would play out thus. In undertaking requirements capture in your usual or preferred way, a business analyst could then identify and map requirements to a library/repository of common requirements. By association,  a sub-set of requirements could be carried forward and they would map into design patterns.  Hence, corresponding code selection. The core of those requirements would be set and re-usable, the associated requirement attributes could be altered but for the most part, remain set. The values of the requirement would be pre-populated and would form a requirement kernel that is both testable and consistent with supporting business operations.

The fly in the ointment, of course, remains that business stakeholders will not be easily convinced that any part of their business is, in fact, quite generic which leaves the notion  of re-usable requirements more theory than fact.  Still I think there is merit in exploring the prospect of realising re-usable requirement kernels.

The motivation was simple. To reduce IT spend. Having been an unwitting partner in this on too many occasions, the reality was something entirely different.

What wasn’t taken into account was the only measure that is truly important. The perception of success. The perception of success is decided fair and square and solely by those who have to use a resulting product and so immediately two schools of thought emerge. The first school of thought runs to the view that we’ve bought a solution, let’s give it a tickle to meet our needs, slap it in, use it and get on with it; no looking back. The other school of thought runs to “Oh myyyy God, what have you imposed on us? This is a dog. It doesn’t do what we need it to do! (My excel spreadsheet has more flexibility than this thing).”

And so we come to configuration analysis and the $6-million question: Where is the line in the sand that overturns the motivation of the Finance Department with their budgets in favour of doing the right thing in the right way by the right people to support the business need?

All too often no one does configuration analysis to determine the answer, after all the COTS motivation is the fait accompli. Part of the trouble lies in another question. What constitutes configuration analysis?

Like the agile approach to software development, it appears to be all things to all men; from the rudimentary to the advanced application of it. To brush over configuration analysis or simply ignore doing it (which occurs all too often) will erode the core objectives of reducing IT spend and getting a solution implemented rapido. Not undertaking thorough configuration analysis also heightens the likelihood of killing the perception of success, and nullifying whatever benefits-realisation was put forward in the foundation business case.

I might have thought that when presented with the option of a build vs. lets buy, that any initial analysis and/or evaluation preceding the business case (or as part of evaluating a tender response) ought to explain clearly why a COTS solution is favoured over bespoke development and independent of what the company accountant is demanding. All too often, and despite their best intentions, the demands of the finance department end up becoming more expensive for a business on levels not just contained to the overall cost and support of a software implementation, and for the reasons mentioned earlier.

All too rarely do I see a real challenge to the argument that a COTS implementation is the better option that will reduce IT spend and deliver more quickly; especially when there are some complex or specific business requirements and/or operations to be accommodated.

I recall all too vividly the mind-numbing grind of Function Point Counting, a technique used to calculate how much software development was likely to sting you for. While that provides the dollars, the constructs used also lend themselves quite naturally towards determining the extent of custom work to be applied to a COTS software package; i.e. against the product shape that typically comprises screens, inputs, database tables, internal files and outputs against an overlaying end-to-end Business Process.

Using these same constructs for configuration analysis, an analyst can figure out the extent of needed modifications against each construct in a consistent manner that holds true as an accurate assessment of how much change is required to twist that COTS package into a workable solution for a business that is a direct comparison with the cost of building something from scratch.

Irrespective of how you determine the extent of modification needed to implement a COTS package, we soon arrive quickly at the tricky bit. Where is that line in the sand? What if 40% of the constructs require 40% modification? That sounds like a lot of change for a COTS to me. But is it? Some may argue otherwise. When you add in the cost of ongoing support and maintenance, consider the upgrade path for such a beast, then the numbers can start climbing and suddenly we’re starting to challenge if the COTS is truly going to be the cheaper or more effective option for a business over the duration of an applications lifespan.

So where is that tipping point whereby COTS solutions stop measuring up anymore for a business? I’m sure everyone has their own feel for where their line in the sand is, and how to determine if you’ve reached it.

Having worked on multiple projects, primarily in the public sector, I have often walked into some very challenging environments.  Systems being held together with string; processes so manually intensive and arduous, it takes an act of God to complete a simple task; and organisational structures with so many reporting layers, communication is just plain ineffective.  The key to initiating a project is to understand your client’s pain points.  This can be accomplished by completing a formal current state analysis, or informally through conversation or observation, watching how business users complete their day-to-day job.  Business analysts can be an ear for business users to vent their frustrations, challenges, and problems with existing systems or processes.  By understanding the current state, a business analyst can recognise issues and needs.  In addition, being able to relate to them allows us to build effective working relationships with our clients and provide them with the assurance to look to us as trusted advisers.  This is vital in our role of providing recommendations when completing a future state analysis and defining requirements, business rules, or business process models.

For a client, a business analyst can be the bridge between the current state and future state; as a result, we are able to facilitate the transition between old and new.  We not only provide support for the present, but are champions for the future.  We are the counsellors that help transform our clients and their way of doing business.