Archive for July, 2007

Business Process Modeling

Published by
Maria Murphy
at 26 July, 2007 in Business Process Modeling. 4 Comments

I have recently been involved in a project that has been ongoing for the last 18 months. In that time, a lot of documentation had been developed and over 80 use cases have been written. The problem is however, that despite this activity, the system development had not progressed and the project is now facing a fast approaching deadline. So, the team is now trying to develop requirements specifications, prototype and build of the system all at the same time. Big Challenge! Aaaargh!

The project manager does not like uses cases and has decided that a process orientation modelling approach is required to meet the deadline. The approach is to develop business process maps from the user pathways, document the information flows, develop prototypes and then build the system. Use cases are “banned” and process mapping is the key focus for Business Analysis and the BA team.

As a BA, use cases have been the main way to capture functional requirements for a system, so at first I was a little perplexed. I thought to myself, “if we don’t have documented requirements specifications (via use cases or an alternate method), then how will the developers know what to build, how will the clients know we have the requirements right and what requirements will we test the system against”? Will process maps be enough?

Anyway, I started to map my processes and sub processes for the system. Myself and the rest of the BA team are working side-by-side with the information architects and developers and as each process map is delivered, a prototype is built and shown to the client area. Sign off and development begins (all within a week). It’s a hectic schedule but it seems to be working.

The business maps are slowly uncovering the business requirements and are a key communication tool for the project team and business area to discuss the “current” and “future state” requirements for the system. The process documentation is highlighting the inputs, outputs and document flows for the system and importantly, the client understands this type of documentation and is therefore able to quickly sign-off on the processes.The project is now gaining some traction and we are progressing well along our time-lines and meeting the deliverable for each stage of development.

I must admit that when I look at the node map for the business processes and sub processes, it does look strangely like a use case “context diagram” and the documentation does indeed specify the functional requirements but as long as we don’t format these documents as “use cases”, the project manager is happy. For me, I guess these documents are not exactly use cases however a “rose by any other name would smell as sweet”.

So this may be a different take on documentation of system requirements for the team but the client area is happy and so far the developers are comfortable with the level of requirements specifications contained in the process maps and associated documentation.

Requirements for Accreditation

Published by
Maria Murphy
at 23 July, 2007 in Accreditation. 3 Comments

 

A friend of mine, Matt, recently blogged about accreditation in the web development sphere and that he has seen accreditation used to:

“define what we do, clarifying and differentiation the different roles within web development, and determining measures for what constitutes a good practitioner and a mediocre one. I’ve seen a lot of discussion about accreditation and certification that is purely academic — a search for identity amongst a wide range of other analyst fields. Some of it is political — the fight control for dominance amongst peers in the community’s space. I’ve also seen that a lot of it is about business and making money”.

Matt prompts us to view accreditation as part of a life long learning process rather than just the pursuit of a “piece of paper” stamped with “version3 “. This is an important point. Accreditation must involve the combination of recognising formal teritary studies as well as experience and relevant course work.

I wrote about accreditation recently so I thought I’d follow up with a comparison of the requirements for accreditation for the two groups I mentioned ABAA and IIBA.

The requirements for ABAA Base Competency Accreditation of “Qualified Business Analysis Practitioner” are as follows:

  • A tertiary qualification from a recognised institution comprising at least four units of Business subjects, and one year of experience in undertaking business analysis tasks, as demonstrated by the candidate’s resume and supporting references or referees; OR

  • Three years’ continuous experience in undertaking business analysis tasks as demonstrated by the candidate’s resume and supporting references or referees.
  • Evidence submitted in support of the assessment request shall comprise the following credentials:
  • A certified copy of the tertiary qualification claimed accompanied by an academic transcript, where assessment is sought through recognition of academic qualifications; and
  • A detailed resume of the applicant including referee contact details for all roles claimed in support of the candidate’s business analysis experience; and
  • Written references from at least two people with whom the applicant has worked (preferably supervisors) identifying their relationship with the candidate and vouching for the experience and tasks completed, as claimed in the candidate’s resume.

The IIBA – Certified Business Analysis Professional requirements for accreditation include:

 

  • Five years (7,500 hours) business analysis work in the last ten years engaged in tasks specifically related to the knowledge areas as defined within the BABOKTM (Business Analyst Body of Knowledge).
  • Demonstrate experience and expertise in at least four of the six knowledge areas in the BABOKTM.
  • Minimum high school education.
  • 21 hours of professional development in the last four years directly related to business analysis or the underlying fundamentals.
  • Two references.
  • Sit and pass the CBAP exam.

The IIBA requirements may be seen are far more stringent (due to the formal examination process and knowledge structure provided through defined areas in the BABOKTM) and may therefore be held in higher regard. The ABAA as an organisation is relatively new but is growing and is still worth considering as it may provide the local contact and regular forums to share ideas and build the profession.

Women in Information and Communication

Published by
Maria Murphy
at 19 July, 2007 in Women in ICT. 0 Comments

I have been a member of WIC (Women in Communication) for some time now. It is an association designed to encourage women to enter the technology and communications industries and provide peer support for those in the industries.

What I find amusing is the reaction I get from some of my male colleagues when I mention that I went to a women’s breakfast. They joke about “secret women’s business”. A male colleague commented he finds such forums divisive. This really surprised me.

WIC actively encourage both women and men to attend their forums and the information, though tailored to mentoring women, is equally valid and applicable to our male colleagues. So please, if you hear about such events and networking groups, be supportive and come along. You are most welcome.

It is fantastic to be a part of something that is helping to inspire women to progress in the technology and communication industries. In particular, WIC is working with other organisations to develop forums where the industries can be promoted to women of all ages but in particular to girls in their last years of high school and at tertiary institutions who are in the process of making career decisions.

The association aims to:

  • provide a forum where women in the technology and communications industry can network for mutual benefit;
  • provide a range of activities to increase the participation of women in the technology and communication industries;
  • provide a forum to develop role models of success to participate in community and school based activities to change the image of the technology and communications industry to one which is attractive to women;
  • have fun.

WIC events are fun and informative. Each month an award, the “WICked” Woman of the Month award, is given to recognise the amazing work done everyday by Women in ICT. These events are a fantastic networking opportunity and are filling a need for support and discussion amongst collegaues in the industry.

Accreditation for BAs

Published by
Maria Murphy
at 11 July, 2007 in Accreditation. 2 Comments

My BA team is currently looking into accreditation. The problem is that accreditation with either the ABAA or the IIBA organisations does not seem to carry the same weight or importance as the PMI (Project Management Institute) or other similar professional bodies.

Also, to date there has not been demand from our clients for professional association membership or certification. Therefore, we are asking ourselves the question - What is the benefit in joining one of these groups? Is it just the networking opportunity or is there a professional development component? Is accreditation a source of differentiation?

I believe that accreditation for BAs is important and worth considering as it will help to develop standards for the group as a profession. When ABAA President Peter Gibbins announced the new accreditation program he stated that “Business analysis is now a critical element of all business improvement projects, ranging from identifying the requirements sought by the change, the business processes affected or to be developed, and commercial impact of the project. There is strong demand for business analysts and, indeed, a shortage of highly skilled professionals yet there is very little objective information to guide either employers or the analysts themselves as to what a baseline level of business analysis competence might comprise”.

Risk mitigation may be seen as one of the main benefits of accreditation. If someone is certified then the client or employer may have a certain level of comfort in the knowledge that the consultant or candidate has reached a certain level of expertise and experience that has been checked by an independent body.

Our team decided that BA membership and subsequent accreditation is worth investigating. We will probably only get out of it what we are willing to put into it. Whilst certification may be of limited value (as clients do not require or demand it of their BAs) this status may change and grow over time. Accreditation (and membership) would give us as BAs , access to a greater body of knowledge through Internet forums, publications, training seminars and the opportunity to network at chapter meetings.

 

The BA as “Translator”

Published by
Maria Murphy
at 4 July, 2007 in facilitation. 2 Comments

I acknowledge that some BAs think their job is done when they hand over the requirements to the developer. I would challenge these BAs, to look beyond the formal requirements documentation and embrace the important role and position they hold in the mind of the business user - that of “translator”.

BAs with their insight into the business, are very much becoming a facilitator and hence “translator” for the business area. They are seen to “bridge” the gap between the business area and the technical group. The business feel comfortable with the BA as “they speak business”and not just “techco”. They workshop the requirements and issues with the business team and work out how to translate this into requirements that serve the needs of both groups. A Business Analyst in the broader sense, is very much focused on the client and its business and therefore has a valuable role to play.

The ABAA recognises that the discipline of a BA is not just restricted to commercial analysts, process analysts and systems analyst and that in fact the work of a BA is a lot broader than these three disciplines. In their draft framework paper, core BA activities are proposed as a starting point by the ABAA. These core activities are then built upon to introduce “the iterative facilitating activities of communication, planning and control; traditional project management disciplines, essential to effectively structure, co-ordinate and drive an analytical assignment”.

This move of BAs into the facilitation sphere may be seen as in conflict with the role of a Project Manager, however I think it is reflective of where the BA profession may be heading. This facilitator role can make the BA role a rich and rewarding experience as you move into a “trusted advisor” role for the business area.


Prototyping

Published by
Maria Murphy
at 2 July, 2007 in Prototyping. 6 Comments

I have an IA (information architecture) colleague Matt,  who often lament that the BA screen concepts he reviews do not reflect user needs nor reflect how the users would like to interact with the system, particularly in a web environment. Matt comments that many of the documented screen concepts are designed to “talk” the developers through the use cases rather than the reflect the business user experience.

I have recently been involved in a project where it was difficult to articulate the needs of users in the requirements specifications, because the users did not really know what they wanted. They only knew what they didn’t want - their current system, which was described as “clunky”. The system was built in software that was no longer supported by the organisation and over a number of years, they had developed a number of manual “work arounds” of this system. The users were hard to engage as they had little time to discuss and review requirements and wanted the system asap. Sound familiar?

So I started with the basics and looked at their current processes, asked how they would like to work in the future, had meetings with various stakeholders and sought their advice on what inputs and outputs were required. The business area had little time to discuss the requirements and even less time to review formal documentation (that was technical in nature in order to inform the development team). Therefore I decided that to ensure I had got the specifications right, I would build a working prototype to show them how the system may look, feel and be used rather than using screen concepts. My aim was to involve the system users in defining the requirements to ensure I got the business needs right.

This concept worked well. This particular prototype was built in Axure, however there are a number of such software applications available that will do the same job. The application was able to simulate a working system and show the users how they would interact with the system rather than just showing them a series screen concepts. The application used allowed users to experiment and make comments about its useability and suitability to their needs. It was very much a communication tool to engage the user and ensure they were involved in the decision making process. The prototyping will be an iterative process to refine the requirements and should result in better definition of business requirements and eventually a better system.