Author: Keith Ellis

What Every Executive Needs to Know About Hiring Business Analysts

Written by Keith Ellis on February 9, 2010. Posted in Articles. 1 Comment on What Every Executive Needs to Know About Hiring Business Analysts

The ability to hire great people is one of those skills that differentiate hugely productive managers from the mediocre. When dealing with a specific project, it gets even tougher with the number of distractions, time sensitivities and need to fill head-count numbers on a project plan. It’s very easy to get sucked into short term thinking, and sometimes HR management practices get short-sighted as well. No, the probationary period of a new hire is not a generic safety net.

Here’s some fast thinking you can do in under 30 minutes to help you hire better:

Get away from hiring generalists

Rather than trying to hire people that are generally great at all things, focus on the areas of greatest value to the organization. Take a few minutes to jot down the services this person is going to offer the organization. Figure out where in the project cycle and which requirements definition and management processes will really impact your organization’s performance. Be brutal in your focus to get it down to one or two areas where this person needs to shine.

By getting ‘service focused’ (verb/noun pairs like ‘Facilitate Requirements Meetings’) you’re being blunt about the competency that is essential for success on the project.

List the Skills Needed

Most companies have defined templates used in their requirements definition and management approach. How many hiring managers look at that document and simply extract use cases, cross-functional swim lane diagram, etc from the template to get a list of techniques the analyst would need to know to be successful. How many people look at the services and say, what techniques would need to be known here to be successful? If you’re looking for requirements definition capability and “Facilitate Requirements Meetings” then you probably want someone who knows the techniques for facilitating a cross functional team.

Want a good technique for listing soft skills? Just list the things that annoy you as a manager.

Test Required Skills

I’m a huge believer in testing skills, before the interview and after the interview. It reduces your reliance on your first impression. It is way too easy to get caught up in thinking the first 30 seconds is the make/break part of hiring. I always end up reminding myself, I’m not hiring a politician. Put more weight on getting the person to do a pre-interview task, get them to do a post interview task and look at the judgment, work quality, and skills used in doing those tasks. Give a documentation focused person a requirements document and say, is it done? Have a facilitator run a simulated facilitation session. Nothing elaborate, just focused on the skills that are essential to success. You could even look to outside organizations that do skills testing (Inquestra, etc) if you’re not feeling particularly creative or need to hire dozens of people and don’t have time to administer the tests.

Get Away from Trying to Hire Industry Experts; Focus on Analyst Skill

Here’s a basic rule of thumb: your line of business managers are the subject experts that know the business. Analysts, need to know analysis. If the analysts are competent, they will function really well, regardless of the industry or position. Granted, if you want a systems analyst for SAP, you need to focus here a little more, but definitely not for business analysts. Let’s face it, the pool of candidates can get really small, really quickly. And chances are, if someone is emphasizing being an industry expert, I’ll bet they are not overly strong in pure analyst skills.

Be Happier

There is nothing worse than dealing with a bad hire. Well… I hate it! Not just the HR stuff, but also what it does to your good performers and the overall project. If your company doesn’t already have great role descriptions in place, try some of these techniques. Having a great team is just a happier place to be.

A Few Thoughts for Those of You Looking for a Job

Lots of folks are out looking for positions today. Here are a few thoughts on positioning yourself for something else:

Consider positioning yourself as a specialist. You do a few things really, really well.
Try putting more active tense “services” you provided to the organization in your resume. Hiring managers (and google) scan for keywords.
List proof of your skills as your accomplishments. (How about: ‘Lead analyst principally responsible for facilitating requirements meetings on over 50 projects’)
Make your expertise as an expert analyst come out

Trying these ideas means deliberately writing a resume that does not fit every opportunity for a contract BA. The idea is to position yourself for certain types of opportunities, and to be successful in landing a spot when one of those types appears. As an interesting side benefit, employers tend to pay more for someone they perceive to be a specialist than they would someone they see as a generalist.

I wish you all great success.

Don’t forget to leave your comments below

Keith Ellis is the Vice President, Marketing at IAG Consulting (www.iag.biz) where he leads the marketing and strategic alliances efforts of this global leader in business requirements discovery and management. Keith is a veteran of the technology services business and founder of the business analysis company Digital Mosaic which was sold to IAG in 2007. Keith’s former lives have included leading the consulting and services research efforts of the technology trend watcher International Data Corporation in Canada, and the marketing strategy of the global outsourcer CGI in the financial services sector. Keith is the author of IAG’s Business Analysis Benchmark – the definitive source of data on the impact of business requirements on technology projects.

Energizing Flailing Projects

Written by Keith Ellis on January 12, 2010. Posted in Articles. 2 Comments on Energizing Flailing Projects

Business analysis is all about detail – the right kinds of detail at the right time. The problem with new projects, especially large ones, is they tend to “flail’, spinning wheels in unnecessary directions as they struggle to gain momentum. Here are some tips and traps to stop the flailing.

Remember

New project concepts seldom have lots of resources on tap, just sitting there waiting to be spent or deployed. Reality dictates that a thin process be used – something that consumes relatively few resources, but takes the project a giant leap forward. Here’s a tip on getting a larger project off the ground successfully: think of ‘start a new project’ as if it were a process (mainly because it is!). Like any process, it has to have five key ingredients: a trigger, an outcome (i.e., building positive momentum), some set of activities people agree are valuable to perform, some set of stakeholders impacted by the process, and enabling resources supporting the process. Keep it simple… if any of these five ingredients are missing a process falls apart (i.e., your project begins to lose momentum).

Many people don’t have a clear image in their mind of what success is when it comes to initiating a project. There are often too many variables, so when you’re in the thick of it, all you’ll have is a general sense of the project building positive momentum, or a feeling that momentum is waning, as unsuccessful tactics consume resources in unconstructive activities. Focus on ‘firming up’ your five ingredients to a process and you’ll feel momentum systematically build.

Here’s how

Business systems are also all about business process. Identify the basic business process areas affected by a new system and start looking at the high level scenarios for each of these processes. Ask how complex each step in a process scenario is, and how well known and documented these processes are, and ask if it is likely that the new business system will impact a particular step in a scenario heavily, moderately or lightly. Then, look at how these basic process building blocks need to share information with outside systems or processes in order for them to function properly. Keep the scenario building for each process high level, once someone uses the words “that depends” when they are describing their high level scenario – you’ve gone far enough. At this point it’s only nice to know how many different variations need to be looked at, it’s not absolutely essential to have documented them.

In this simple set of above steps – what is happening in the five key ingredient areas?

Scope. You’ve quickly identified the magnitude of analysis work (number of processes, number of use cases, complexity of these use cases)
Stakeholders. You’ve identified the stakeholders (who interacts with the process in conducting the activity or as a user or supplier of information to the process)
Activities. You will frame up a plan of action (once you know the use cases, you specify the plan for detailing each of these) so you know the steps that need to be taken to get requirements fleshed out.
Resources. You can then estimate the amount of effort needed to complete the analysis of the business processes so you know how much resource is expected from stakeholders. You can do this because you know the number of use cases (approximately), and know how long each stakeholder has to be involved.
Trigger. Once you get agreement to the requirements definition plan from the business and technology, including agreement from the business and technology to provide specific resources to participate in specific ways to complete the plan.

Once agreement happens, you have a project!

Compare this listing to the five ingredients. Does the above sound like a decent process for kick starting a new project?

The business analyst trap, in initiating projects, is to get caught up in complexity. Some of you will recognize my recommended approach as a requirements planning process – it’s fast, efficient, and can be used to energize projects that are flailing. The only problem is… very few people do it. Requirements planning is not about simply filling in another template; requirements planning is about gaining significant momentum on larger projects very quickly.

Don’t forget to leave your comments below

Four Trips to Midnight

Written by Keith Ellis on December 1, 2009. Posted in Articles. 1 Comment on Four Trips to Midnight

Midnight is a dark time, like a looming deadline which you’re pretty sure you can’t meet. No one is ever sure exactly how they got into the position of running up against midnight, but it usually means long hours late at night – and lots of caffeine. Perhaps it also includes a dose of wistful thinking and wondering about the project plan that seems to be growing like David Banner in a snit. Sometimes it happens, the work load just got misjudged, or the magic of juggling priorities and fate landed a few choice lemons in your lap. Maybe it’s a different problem altogether.

I’ve noticed lots of analysts have trouble with estimating the amount of time it will take to complete business analysis and the elicitation and documentation of requirements for a project. I remember evaluating a team where the most forgiving management stakeholder I interviewed stated they were currently at 300% of the expected time needed to get requirements – and that was just her personal time… not elapsed time (which was months over schedule). Estimating analyst effort is tough because business analysis is inherently about taking a concept that is airy-fairy-fluffy, and turning it into something that is concrete-with-dimension. Here are some ideas to think about late at night – hopefully some of these will prevent you from burning the midnight oil on your next project.

Your company might be lousy at scoping… It’s crazy the number of companies that don’t stick a little micro-engagement on the front end of their analyst work effort. The only purpose of the engagement is to figure out how long (with reasonable precision) it will take to do requirements, and to figure out the plan to get these requirements done. Sound silly – a plan to do the plan? On the contrary, it will likely end up as the highest value you offer as an analyst organization. Remember, many companies also spin for months on very early stage projects with little to show for it – this micro-engagement will break that spin cycle. The other added bonus is that high quality requirements plans keep stakeholders engaged, and that makes it more efficient for everyone.
Your company might have ambiguously defined process and outputs… This situation is like trying to shoot a bulls-eye while riding a mad bronco while shooting at a bouncing target. Hitting it ain’t going to happen! In my early years, I once had an executive say at the end of an engagement, “can you get some more business context into those requirements?” I said, “we’ve already documented the process flow, data flow, business rules, for every process in the business and used these as the basis for the business requirements, I also have a context diagram, business objectives, and good representation of the issues and interdependencies. What’s missing?” I guess he figured I had his funding plan all figured out too. Get some precision on the expected outcome and what that means before you start committing on timelines.
Lousy practices (ouch!)? OK, so this shouldn’t be rocket science, but you might want to try breaking analysis down into Use Cases, Business Events, User Stories, or some other collectively-inclusive-yet-mutually-exclusive bits of work. Then estimate how many of these you have. Start with the business process areas, how many big processes are we dealing with, how many Use Cases in those processes, etc? Here’s the magic bit… keep track of how long it takes you to do one for you and other members of your team.
Maybe it’s the review process that needs improvement? Some review processes have very little end in sight. Especially ugly is the organization that expects to get business signoff on very detailed systems specification with lots of techno-babble. I did some consulting for another company that was big on peer reviewing. Peer reviewing is great, but every reviewer at that particular company did requirements a bit different, so it was driving the analyst teams nuts and creating lots of inefficient rework. It will save you lots of time and effort if you get a clear expectation of level of detail, form, format, and maybe even get agreement from the stakeholders on what a good requirements document looks like before you get underway. At least that way, you can show the reviewers what the agreed upon target looks like – or walk recalcitrant stakeholders and sponsors through the templates that worked so well on that other successful project. Then show them how yours provides the same level of detail, and walk them through the process through which that detail was assembled.

Here’s a secret – only a small minority of companies actually produce requirements plans on projects. Yet many of you end up burning the candle at both ends trying to meet a somewhat arbitrary deadline on the requirements preparation. Don’t stay on a train that will keep taking you to midnight over and over. Step back; it might be time to change the process.

What’s your favorite cause for a trip to midnight?

Don’t forget to leave your comments below

The Future of the Business Analyst

Written by Keith Ellis on November 3, 2009. Posted in Articles. 1 Comment on The Future of the Business Analyst

Many of us are in that crucial planning point of the year when we’re looking forward to what our key initiatives will be for 2010, and with this forward-looking mindset, I thought it might be fun to look forward 10 years or so and speculate on the future of the Business Analyst. Violently agree or disagree if you will with my thoughts – I think the important issue is to create a dialogue, and get people talking.

In a prior life, I spent almost 10 years as an executive at a technology trend forecasting firm. A few bits and pieces to share with you from that experience:

People tend to overestimate change over the short term, but under-estimate the impact of systematic and continuous change over the long term. In 2000, the Internet flurry created an unsustainable bubble founded on short term profit belief. Now, ten years later, the revenue, profitability and transformative effect of the Internet is generally acknowledged.
Every few years, a different wave of focus will come along which re-energizes a concept. Time and motion studies became re-engineering which is kind-of-like SOA and enterprise architecture.
Modernization never really happens… or more accurately, as soon as you modernize, you’ll need to do it again. Mainframe, Mini, client-server, SAAS, Cloud.
Devices gain way more intelligence.
The pace of change accelerates.
We figure out how to do more with less.
People find more ways to communicate, socialize and build community.

Here are my, out-on-a-limb predictions; and I’d encourage you to put your own out there. Let’s look out over the next 10 years. By 2020:

Requirements practices will mature amongst F1000 companies dramatically. This will further fuel the ‘professionalization’ (if I can make up a word) of the analyst function. We’ll see a dramatic rise in performance expectations of individuals and the analyst function. Over the last three years I’ve seen huge strides forward in this area, but I think it will still take a few more years for us to start hearing CEOs talking about business requirements and business analysts in the same sentence as they use the words strategy and competitive advantage.
I think you will see a sub-group of this F1000 that are differentiated in their ability to get more successful, technology-based products and services into the market, faster. With this group, the requirements function will play a big role. We’ll see far more examples of ultra-high requirements maturity organizations and see public stories that showcase the impact of continuous optimization.
Technology for analysts will become much more holistic and cover the spectrum from scoping and elicitation through to QA. The technology will also be more SDLC method independent, so that analysts can accommodate more domains of analysis. Today’s tools tend to be fairly task-specific and limited to one of process flow, or data flow, or managing structure statements of system capability, or modeling, or stakeholder communication, or system visualization – or – they are locked to a specific layer in the requirements life cycle. Task oriented tools are fine, but I think we’ll see an explosion in new players in the market before a rationalization occurs by the time we get to 2020. The winners in this will provide analysts with a well-rounded capability across all those elements above in a well-rounded tool-kit and tight integration into both other layers of the SDLC and other critical change functions. IAG already tracks over 100 tools principally designed for analysts at IAG – in the near future, we’re going to see many more.
Establishing business requirements will take far less time. Dare I say a fifth of what it is today. What you did with stakeholders over half a year, you’ll be accomplishing in a month on average? Why is this important? I think application complexity will continue to rise, I think organizations will continue to remain flat, and analysts will have to respond with far more efficient mechanisms for engaging essential stakeholders, if they are to achieve their objectives.
I think you’re going to see more expansion in the analyst role definition, greater centralization in the organizational specialists that play these roles, and more fusion between business analyst, project manager, portfolio manager, change management and business architecture roles. Business transformation is a strategic function that companies will continue to optimize. We may see this function within the business used as an incubator for developing senior executives.
We’ll see at least two major shifts in SDLC and another two in IT infrastructure/architecture. In five years, will we be talking about Agile – or will we be talking about something else that looks even more promising and scalable. Ten years from now, pundits may be shouting “Scrum is dead” and “cloud computing is the way of the past”. I think organizations may increasingly decouple requirements practices that set need from these other areas which deliver on the need. All analyst methods, project manager practices, SDLC disciplines have techniques that are solid and can be applied within the analyst function regardless of the SDLC is in place. I think you’ll see fewer ‘purist’ shops, and more ‘practitioner’ shops that have a strong framework in place – and adapt new ideas into it, rather than making wholesale changes to the framework.
If I were a betting man, I’d say we’re going to see a massive upswing in the collaborative nature of the BA role. I think Agile is the first of many ‘team-centric accountability’ models for development. If we go into the future and envision an Agile 2.0 somehow harmonized with Plan Driven 9.1 the key to success in that world would be managing controlled and efficient collaboration of business needs on a more massive and virtual scale. Rather than three people in a Scrum, how about 100 in a Scrum 2.0? This would require tremendous skill, automation and collaboration on a scale we’ve not seen yet.
We’ll see greater virtualization, globalization, and automation in mundane analyst activities. As the importance of the activity rises, so too will pressure mount on the function to scale at a lower cost by off-loading non-strategic activities to other delivery channels.
We’ll see ‘twitter 2.0’ and a future generation social media/information sharing technologies integrate themselves into the analyst function.
We’ll see a reemergence in focus on data and how information moves within organizations. From my perspective, this one is getting a little lost in the shuffle and there is lots, and lots of room for improvement.
You’ll have ten more years to gain wrinkles and grey hair… and, by then, someone may have figured out a pill to deal with that.

The BA role has always struggled; it has responsibility without authority. This will never change. As a result, the optimal model for any particular business will continue to swing between centralization and decentralization as businesses wrestle to establish the business analyst role in the value chain. What I think will eventually break this gyration is the economic concept, ‘specialization of labor’. Specialized work-forces are more efficient. What we may see emerge is a more specialized class of very high value BA which the business recognizes has an integral role in the value chain. What happens to the lower value roles, and less specialized team members? These are likely vulnerable to globalization, automation, cost reduction, and the whims of SDLC focus.

Who knows what the future holds – I certainly can’t predict it. I think that in speculating on what this function looks like 10 years from now, there is an opportunity to think about what is strategically valuable in the function today. I also think, while some organizations may be decades away from being able to achieve this vision, some of you are already well along the path.

The future is closer than you think!

Don’t forget to leave your comments below

Business Analysis Benchmark – The Path to Success

Written by Keith Ellis on October 13, 2009. Posted in Articles.

The Business Analysis Benchmark is a large scale survey effort designed to assess the link between an organization’s maturity in requirements definition and management and project outcome. This year’s theme is The Path to Success; the study presents detailed findings on the impact of business requirements maturity and analyzes the strategies and tactics needed to implement enhanced requirements maturity.

“This survey is a testament to the need for investing in your requirements process to deliver value to your stakeholders.”
Scott Hebner, Vice President Marketing and Strategy, IBM Rational Software

The Requirements Maturity Model (RMM) is a means to benchmark an organization’s effectiveness in requirements definition and management by looking at maturity in six underlying capabilities. Like similar standards-based models, it classifies companies based on observed, tangible competency in each capability to make an objective assessment of overall maturity. Using this approach, the report found:

Requirements maturity improvement is highly correlated with improvement in development effectiveness.
Requirements maturity cannot be changed through continuous focus on only one underlying capability.
High requirements maturity companies can be found amongst the followers of many different approaches to development such as Agile, Iterative, Plan Driven (Waterfall),and Prototyping/Visualization centric methods.

The above findings validate the Requirements Maturity Model as a mechanism for identifying the impact of poor requirements practices on companies, quantifying the performance change expected for a particular organization’s situation, and, diagnosing the changes needed should a company choose to pursue a path of improvement. This report identifies both the strategy and tactics of enhancing requirements definition and management maturity. The statistics presented in the Business Analysis Benchmark not only debunk a number of commonly held beliefs about development effectiveness, they show that the average organization wastes a large proportion of its IT development budget due to poor requirements maturity. To be clear, 75% of organizations surveyed waste over one in three dollars spent in IT development and implementation annually as a result of to poor requirements maturity. These findings detail key issues and actions needed to recapture this wastage.

Key Findings of the Business Analysis Benchmark include:

Requirements maturity has a strong positive correlation to EVERY major measure of development efficiency assessed. On-time performance, on-budget performance, on function performance,

“This [report] was extremely helpful to me, not only to understand the findings relating to my current situation, but also what CEO and CIOs are interested in.”
Carol Deutschlander,
Home Hardware Stores Limited

overrun magnitudes for each of the above, and project success rates all improve as requirements maturity increases. On average, performance virtually doubled on each of these metrics as organizations progressed from using an ad-hoc approach for requirements definition and management to having institutionalized and consistent competency in all capability areas.

Average on-time performance of technology projects increased by 161%.
Time overruns on projects reduced by 87%.
Average on-budget performance for technology projects improved by just over 95%.
Budget overruns reduced by just under 75%.
Percentage of projects that deliver the functionality needed by the business rose by just over 75%.
Average functionality missed dropped by approximately 78%.

A total of 74.1 per cent of survey respondents were classified as immature Level 1 or Level 2 organizations (where the highest maturity Level is 5). These organizations waste 39% and 34% respectively of their development budget due to poor requirements definition and management maturity. This wastage, due to poor requirements maturity, will increase to over 50% of IT spending on development and a significant proportion of the maintenance budget in certain circumstances.
Poor requirements definition and management maturity undermine organizational competitiveness. Organizations with poor requirements maturity expend far more time, budget, and management effort to achieve the same results as organizations with high maturity. For example, organizations with low requirements maturity achieve the business objectives of a project initiative a mere 54% of the time while taking 35% more time to achieve this poorer result. This impact may be so significant over time that it shifts fundamental financial performance metrics such as Return on Assets (ROA).It was found that Level 4 companies, on average, outperform the ROA of their peer group competitors by 10%.
While this report discusses and busted a number of commonly held beliefs about requirements and development efficiency, two issues garnered significant attention and support from the report’s external review panel:

CIO’s cannot simply attempt to hire great analysts and expect the problem of poor requirements to go away. In fact, lower skilled people in a high requirements maturity company significantly outperform highly skilled people in a low requirements maturity company.

“I’ve worked carefully through the Benchmark Study. It’s terrific stuff — some of the conclusions are almost iconoclastic, and yet they make tremendous sense once you analyze them. And the RMM is an excellent tool — of course it does and should heavily parallel CMM / CMMI, but it also provides tremendous value added as you’ve applied/customized it to Business Analysis practice.”Senior Requirements Specialist Major Property & Casualty Insurance Company

Agile, Waterfall, Iterative, Prototyping/Visualization have immaterial performance differences for any given level of requirements definition and management maturity. There is a raging debate amongst development methodologists, each espousing one method over another. This study finds that changing development methods – in the absence of also improving requirements competence in the areas of process, techniques, staff, technology, organization and deliverables – only nominally improved or reduced overall success rates on projects. Excellent results have been achieved with all these approaches, and the findings of the Business Analysis Benchmark do not endorse any one method over another. The key issue for readers: the overall level of requirements maturity has a MUCH greater effect on project outcome than the development method selected.

The Business Analysis Benchmark describes the issues and impacts of each level of the organization, and the role each plays in moving a company forward along the path of maturity. This report has a preface that describes the survey, maturity model, and basic facts surrounding the impact of requirements maturity on project outcome. The remainder of the report is organized along the lines of a readership group, discussing the key findings as they relate to:

The CEO: how does requirements maturity impact overall organizational competitiveness?
The CIO: how does IT Leadership approach the major issues in making requirements definition and management change?
The PM and BA Leadership: what is the effectiveness of various paths of change, and what are the required activities to bring improvement? In addition to this content, IAG has also asked a series of external reviewers to comment on survey findings. Some of these insights are captured in the call-out boxes in this article.

The Survey – How it was Conducted

Last year, over 22 million business and IT professionals in 80 countries, and using 10 languages, benefited from the statistics generated by the Business Analysis Benchmark.

This year’s survey theme – The Path to Success – identifies a roadmap for maturing requirements definition and management practices. This study is about getting repeatable success on strategic IT projects.

In Q2 of 2009, just under 550 companies chose to participate in the Business Analysis Benchmark – Path to Success survey, leading to 437 qualifying responses. This survey was designed with the intent of assessing the link between an organization’s maturity in requirements definition and management and project outcomes. The Business Analysis Benchmark statistics only include respondents that met the following three criteria:

The company spends over $1 million annually in application development (net of hardware) or software implementation.
The individual must have experience with business requirements and project management where net new functionality is added to the business.
The company must have run at least four projects in excess of $250,000 in the last 12 months.

These criteria ensured that only experienced professionals with knowledge of requirements definition and management issues would be included in survey results. The results are weighted toward medium and large sized commercial companies, in North America. The sampling is summarized below:

Position

Executive: Head of IT, CIO, Head of Development, Line of Business Executive
Head of PMO or Project Manager
Head of Business Analysis Competency Center or BA
Other

Number of Employees in Company

1‐99
100 to 499
500 to 2,499
2,500 to 4,999
5,000 to 9,999
10,000+

Industry

Energy, Resources & Utilities
Financial Services
Insurance
Government & Social Services
Healthcare & Pharmaceutical
Manufacturing
Media & Industry Analysts
Military & Defense
Professional & IT Services
Retail, Transportation & Distribution
Software
Telecommunications
Education
Other

Region

United States
Canada
Western & Eastern Europe
India/Pakistan
Asia/Pacific
Africa (mainly South Africa)
Middle East
Central/South America
Total

% Respondents

12.2%
27.1%
52.5%
8.3%
100.0%

% Respondents

6.2%
14.3%
20.3%
11.5%
8.5%
39.2%
100.0%

% Respondents

3.9%
17.7%
9.9%
8.7%
8.0%
6.0%
1.1%
1.4%
14.4%
5.0%
9.2%
6.7%
2.1%
6.0%
100.0%

# Respondents

233
116
26
24
22
6
5
5
437

Don’t forget to leave your comments below

Keith Ellis is the Vice President, Marketing at IAG Consulting (www.iag.biz) – and author of the Business Analysis Benchmark – where he leads the marketing and strategic alliances efforts of this global leader in business requirements discovery and management. Keith is a veteran of the technology services business and founder of the business analysis company Digital Mosaic which was sold to IAG in 2007. Keith’s former lives have included leading the consulting and services research efforts of the technology trend watcher International Data Corporation in Canada, and the marketing strategy of the global outsourcer CGI in the financial services sector.

For access to and to download your free copy of the full Business Analysis Benchmark study, please click on www.iag.biz.