Search This Blog

29 March 2007

Earn more than $5000 per week and enjoy your job

I posted this article to Helium. Its for the many people on Monster and IT Toolbox discussion boards who want to break into the business analyst role but don't know how.
Earn more than $5000 per week and enjoy your job.

How do you become a top Business Analyst? How do you break into the Business Analyst role?

The Business Analyst, or BA, is a key role in technology and corporate projects. The BA is the right hand to the project manager. BAs are there to make sure the business problem is understood and that the right solution is implemented. The key skills are conceptual thinking and communication.

As you can see it’s an important and strategic role, and that is why you get paid so much to do the job.

Of course most BAs don’t get paid $5k per week. In Australia the job usually pays between $60-90 thousand, but good, experienced BAs earn much more. More than $2000 per week is common.

There are usually two paths to becoming a BA.

The first and more traditional is from developer to lead developer then to solution designer and then BA. The pathway is focused on working on requirements at the detailed level and moving up to the higher conceptual levels of design to specification and eventually working with people to understand requirements.

The second and more modern way is to come from an operations area. Usually you have a degree in business, IT or engineering and have landed yourself in a frontline role. Your conceptual thinking skills have made you the local problem solver and process expert. You eventually become a subject matter expert of a project. One project turns into several and then you are seconde into a role as a BA.

A third path is to come from the high pressure world or management consulting across to a corporation to work as a project manager/BA. A BA is like a management consultant without the hubris and living in the tactical world of project delivery. Consultants that become BAs often find they love the role because they are more respected, better paid and they have the kills to do the job very well.

Once you get the gig don’t rest on your laurels. You are a junior consultant. You must learn more. Read blogs and books. Network with senior BA and join your local project management or business analyst association.

If you want to reach the $5k per week rate work hard and make sure the people you work with respect what you do and how you do it.

Good luck.

27 March 2007

Web 2.0 ... The Machine is Us/ing Us

26 March 2007

Business Analyst Knowledge Domains

Business Analysts, like IT project managers should have a couple of knowledge domains under their belt.

Project Managers should know project management, plus a bit of management, plus a bit about the industry they are working on (and for anyone involved in IT) plus a bit about software development.

Business Analysts should know business analysis, plus software development, plus a (fair) bit about project management, plus a bit about the industry they are working on.

The PM BOK used to represent this as three areas overlapping (and then in the latest PMBOK migrated to a more complex but less elegant model of multiple knowledge domains.) For the business analyst the idea could be represented like this;

The most important thing the business analyst should know is the foundation level information surrounding requirements elicitation, requirements management and stakeholder management. Beyond that they become more effective as a project team member if they also understand other things about the context they are operating in.

Project Management
If a business analyst does know something about project management they become more effective because they can work more independently, they understand the project manager’s motivations and constraints better and they can run projects within the overall project or programme.

If a business analyst does not have project management skills they will often clash with the project manager, the sponsor and other project participants as they can become overly focused on the requirements as requested/stated by the business subject matter experts. This situation may find them acting as a gatekeeper to change rather than someone actively contributing to project success.

Software development
Most projects a business analyst works on will involve some degree of software development. It may be as simple as adding a new price to a database or it may implement a suite of new enterprise management systems.

Regardless of the complexity it is important for the BA to understand the processes and systems used by technical teams. Often the BA is the intermediary between marketing, operations and IT staff. They are expected to mediate, translate and facilitate discussions across a business’ functional areas. To do that effectively they need to be able to speak the language of the technical team.

A BA that does not understand the software development lifecycle will have trouble understanding what the consequences of decisions made will be down the development track. They will also have trouble drilling into the technical detail and explaining how requirements have been met, or not met, to business stakeholders.

This will also help develop trust and empathy from the technical team. They will see the BA as their point man in the treacherous world of marketing. Marketers and operations people will also see the BA as their point man in enemy territory if you learn to speak their language also. That’s where industry expertise comes in handy.

Industry expertise
Business analysts often start their careers in operations roles as subject matter experts or managers and have a history of “getting things done” in a company. They often understand the infrastructure, personal networks and regulatory frameworks a business operates in. They bring with them an ability to know the right questions to ask and the ability to drill into key issues faster.

Business analysts without a background in at least one industry often have trouble getting hired. It’s seen in the many posts on the jobs message boards where graduates and junior IT professionals ask how they can become BAs. Having experience in the operations end of an industry is the answer. Not only does it give you the advanced insight into requirements, but it gives management a certain reassurance that you can “get things done.”

That’s not to say BAs can’t travel across industries. It just indicates that junior Bas are more likely to emerge from operations teams that be hired across industry for their first BA job.

Related documents
Both Project Management and Software Development have published Bodies of Knowledge documents. Business analysts interested in doing their job well should make sure they read them both, as well as the BABOK.

Project Management's PMBOK –
Software Engineering's SWEBOK -
Busniess Analysts' BABOK –

21 March 2007

RATER; the gap between expectation and experience

The RATER (Servqual) service quality framework asks customers about their expectations and experiences across the five RATER dimensions of quality. The measure of quality is the gap between expectation and experience. If the experience was below expectation, the score will be negative. If the experience is above expectations the score will be positive.

Example questions for a RATER style customer survey are provided below. If you are a business, you should ask your customers what they think of you.

If you are a member of a project team, maybe you should ask your stakeholders the same questions. You should definitely consider these factors in the delivery of your work.

Ability to perform promised service dependably and accurately
  • If a response is promised in a certain time, does it happen?
  • Are exact specifications of client followed?
  • Are statements or reports free of error?
  • Is service performed right the first time?
  • Is level of service same at all times of day and for all members of staff?

Possession of required skill and knowledge to perform service

  • Can staff provide service without fumbling around?
  • Are materials provided appropriate and up to date?
  • Can staff use the technology quickly and skilfully?
  • Does staff appear to know what they are doing?

Trustworthiness, believability, honesty of the service provider

  • Does service organization have a good reputation?
  • Do staff members refrain from pressuring the client?
  • Are responses given accurate and consistent with other reliable sources?
  • Does the organization guarantee its services?

Security: Freedom from danger, risk, or doubt

  • Is it safe to enter the premises and to use the equipment?
  • Are documents and other information provided for the client held securely?
  • Are use records of clients safe from unauthorized use?
  • Can client be confident that service provided was done correctly?

Appearance of physical facilities, equipment, personnel, printed and visual materials

  • Are facilities attractive?
  • Are staff dressed appropriately?
  • Are written materials easy to understand?
  • Does technology look modern?

Making the effort to know customers and their needs.

  • Does someone on staff recognize each regular client and address them by name?
  • Do staff try to determine what client's specific objectives are?
  • Is level of service and cost of service consistent with what client requires and can afford?
  • Are service providers showing politeness, respect, consideration and friendliness
  • Does staff member have a pleasant demeanour?
  • Does staff refrain from acting busy or being rude when clients ask questions?
  • Are those who answer the telephone (or emails) considerate and polite?
  • Do staff observe consideration of the property and values of clients?

Listening to customers and acknowledging their comments; Keeping customers informed in a language they can understand.

  • When client contacts service point, will staff person listen to their problem and demonstrate understanding and concern?
  • Can staff explain clearly the various options available to a particular query?
  • Do staff avoid using technical jargon when speaking with clients?
  • Does staff member call if a scheduled appointment will be missed?

Willingness to help customers to provide prompt service

  • When there is a problem, does organization respond to it quickly?
  • Are staff willing to answer client questions?
  • Are specific times for service accomplishments given to client?
  • Are public situations treated with care and seriousness?

Access: Approachability and ease of contact

  • How easy is it to talk to knowledgeable staff member when client has a problem?
  • Is it easy to reach the appropriate staff person (a) in person (b) by telephone (c)
    by email
  • Are service access points conveniently located?

Periodic Table of Visualization Methods

The fine people at have come up with some great ideas for representing information in fresh and intersting ways. A highlight from their website is this Periodic Table of Visualisation Methods. When you click through to the page you can mouse over each of the elements and get a floating summary and images of the technique in play.

If you are stuck for ideas in your next presentation, or want a new tool for a workshop check it out.

20 March 2007

A History of Business Analysis

Andrew Arch is an entrepreneur, software designer, and team leader. He contributed an article to the Business Analysts Handbook which looks at the context of where a business analyst works; the history and convergence of management and quality systems and software engineering. He writes it as a context for what a Business Analyst needs to know in order to be a useful and valuable contributor to the project team.

I asked him why he wrote this long, yet fascinating, history of the world the business analyst inhabits and he responds;

“I have the attitude that to know today, you must appreciate yesterday, and to predict tomorrow, you need to know the trajectory through today, if that makes sense. So in order to write anything on process, or documenting, you need to place what you are discussing in some form of historical context to validate it.

“The idea I vaguely have in my mind is that any processes or methodologies that you document should be either added to this history or not included. That way people can appreciate what its origins, strengths and weaknesses are and potentially what its alternatives are for a particular ideology.

“Then from that historical list you can start organising the wiki against various themes: ideology, historical lines, etc.

“Plus, I have done this exercise in a more limited way a number of times when taking on new graduates and even more experienced developers and BA's when attempting to set the context for why we do or choose certain approaches. To do that, you need to explain what the approach addresses or attempts to, and how effectively it does so against its alternatives and then you are led to why the alternatives exists, and before you know it, you have done some historical lesson.

“So I figured if I did this the once like this, then I could refer to it instead of relying on my hazy memory. So my personal itch.

Thanks Andrew for the contribution.

15 March 2007

Blooms Taxonomy and the Business Analyst

The IIBA is working on developing the Business Analysts Body of Knowledge (or BABOK.) Part of what they will do in this role is define what a business analyst is. It's a tough job and they have started with looking at defining the role by what is unique about it. For example, even though many BA roles share many competencies with, say a systems analyst or a project manager, those competencies are not included in the definition of what the BA is.

Defining the role of the business analyst will also require defining levels of competency in the key skills and knowledge areas. Bloom's taxonomy may provide a useful framework to leverage.

Bloom's taxonomy is a 60 year old categorization of levels of understanding in learning environments. It breaks down understanding into six classes. These were originally:
  • Knowledge,
  • Comprehension,
  • Application,
  • Analysis,
  • Synthesis and
  • Evaluation.

The classes have since been challenged and modified a little but remain essentially the same. Each of these classes represent a progressively deeper understanding of and ability to use the knowledge gained in the relevant subject area.

It seems to me that this framework could be applied to a business analyst's understanding of requirements. Eliciting, defining and managing requirements means learning about the business operations, the need for change, the vision of the future state and so forth.

The business analyst, depending on their level of understanding is then able to apply critical thinking and problem solving skills to determine what the business requirements are. These ideas contrast with a common experience project managers and stakeholders often have of business analysts. Many BA’s capture requirements statements from subject matter experts, adding little or no interpretation or extra analysis to the requirements elicitation process.

In Bloom's taxonomy, knowledge, for example, means that a student (or business analyst) knows that something exists and is probably able to describe its physical attributes. For example an operations business manager may state a requirement and the business analysts will capture it and repeat verbatim in a requirements statement.

Further up the learning hierarchy Synthesis may mean the business analyst understands what the operations manager is saying they want and is able to interpret this basic requirement statement into what is critically important and what is just a repetition of the status quo and thus state a requirement in the context of the business's future state, stripping it of superfluous attributes.

This level of requirements analysis often enables greater steps forward by the project as artificial constraints created by poor requirements statement are managed away.

Here are a few references where you can read more about Bloom's taxonomy and its place in the education industry.

12 March 2007

Marketing Projects: Table of Contents

"Internal Marketing for Projects"
Table of contents

I have renamed the chapter headings here so they won't be the same as on the original post. I have done this to be clearer about the content and context of each article.

This series of articles focuses on the idea of marketing internal business change projects to internal stakeholders. Think data warehouses, CRMs and so forth.

I hope the ideas are useful for you and help you think about better ways to achive success in your projects. I welcome any comments and discussion.

9 March 2007

Marketing Projects: Internal Marketing

How can implementing marketing principles into project management improve project’s performance?

Professor George Day writes about how marketing competency can link originations’ capabilities to create customer value. He asserts that this occurs through the marketing attributes of ‘sensing, customer linking, and channel bonding.’ Customers are linked to the internal competencies of the marketing organisation, or in our case the project management organisation and that’s how they extract value out of the relationship.

While a project team may be fine at delivering to specification it takes an awareness of the customer’s needs and wants, an ongoing relationship with them. The project also needs an agreement from the customer that the relationship with the project is one they value and to want to maintain at least for the duration of the project.

This aligns with Project Management literature that says the relationship with the client/sponsor/stakeholders is key to success in so many various ways, from open sponsor support to general stakeholder buy-in and acceptance of the change.

To improve chances of success the project should be building their relationship with all people who have influence in how the project outcome is perceived. This includes the frontline staff, stakeholders, and middle management as well as the sponsor/client.

Marketing your project to these audiences before you are ready to “go live” should improve their perceptions of success, even rasing the organisation’s level of desire.

I will end this discussion here (for now) with a link to an article on internal marketing for IT departments. Have a read and consider whether the points discussed could be applied to your project.

The Secret Weapon: Internal Marketing
It's the best kept secret for success: Marketing IT's achievements will boost its credibility, create transparency and might even help win instant approval for your next $2 million project.
By Alice Dragoon

Reference: George S Day, (1994) ‘The capabilities of market-driven organisations’ Journal of Marketing Chicago, (Oct 1994) Vol 58, Iss 4, pg 37, 16pgs

6 March 2007

Marketing Projects: Marketing for Success

Marketing is about relationships. So is project success.
Marketing is oriented to an ongoing relationship with clients and customers, where project management has traditionally been focused on a one-off delivery. Success is more likely to come if you have a good relationship with your client, and that’s not just because they will be more forgiving. It’s because there is a dialogue.

The growth in programme management and projects in modern business mean that project teams and project offices are taking a more relationship oriented approach to their clients.

For a start, project teams and project firms are more likely to bundle service and maintenance packages into the contract with the client, meaning that the relationship between parties is extending beyond the project period.

Projects release end products that are used by customers or employees into the future and the impression of a project teams success and/or failure and other impressions of value and quality will come from both the users and the stakeholders that the project deals with directly, and getting those stakeholders and users to buy-in to the project is critically important. It will also change over time as the users and beneficiaries of the product get past the shock or excitement of the change into the new mode of operating.

If a relationship exists beyond the function of build and deliver success is closer.

Marketing Projects: Projects fail. Can marketing help?

I am exploring whether applying marketing principals to projects has the potential to improve project success rates. The sorts of projects I am talking about here are things like implementation of new enterprise systems such as CRMs, data warehouses and the like.

In the previous post I looked at what success means for a project and came to the conclusion that it’s a complex issue, but for the sake of this discussion we’ll call it a happy customer.

I have also looked at how projects support corporate marketing strategies and where marketing sits in the modern organisation.

In this post I had planned to look directly at how marketing can help projects, but before I go into that let me spend a few minutes differentiating marketing from change management (aka implementation management.)

Effective change management is widely acknowledged in the Project Management industry as a critical area that needs to be addressed by the industry (Badham et al, 2001.) The how-to of change management is less clearly understood. I propose a marketing framework for managing the activities of change management.

By the way, each time I write “change management” in this context I realise that the usual PM lexicon uses the term differently. What I am talking about here is implementing the change into the organisation. The “change management” of the PMBOK should really, in my opinion, be called Scope Management. Anyway; my definition: Change Management is the bit in the project lifecycle where the receiving organisation changes from it’s old state into its new fangled future state, using whatever products the project has created.

So, change management is an important step in the project lifecycle. It can (and should) begin right up the front, but it’s at the end that it really happens and the change management activities are executed. Whichever methods and activities are used they are about the handover from the project to the owners of the system/process/product, and about the transition from the current state to the future state.

I have written about change management methods and approaches here before and probably will again. For now, let me say that change management is the activities that form the handover to and transformation of your client. Marketing is something else again and can be a part of the change management activities, but is also separate from it.

Marketing Projects: Success is a slippery thing; a temporary definition

Everybody knows plenty of projects fail but what can be done to improve their hit rate? My proposition in this series of posts is that applying marketing principles could improve project success rates.

I have looked at a couple of areas where projects do use marketing; specifically in projects that are building end user/customer products. Even there is seems that marketing has become more strategic than mere product development.

I have also looked at where marketing sits in organisations these days (high up in the strategisphere) and how projects are used in fulfilling marketing strategies.

Moving past the obvious point that product development needs to consider marketing principles I want to look at how marketing principles can assist projects like CRM, Data Warehouse and similar operations projects. I chose these types of projects as they are less likely in the normal course of managing projects to consider marketing as a tool to help them achieve success. You should be able to retrofit any principles I come up with to dealing with the customers.

Success is a slippery thing in the world of corporate projects, so before I go on I want to spend a moment talking about what project success is.

For a start project scope is often poorly or, at best, loosely defined at the inception of a project. Without a period of intensive analysis there is rarely an opportunity to know how complex and challenging the project will be compared to the often simplistic vision of what the end product will be.

Projects are iterative.
They are constantly reviewing the problem and revising the solution. Sometimes you won’t really know what success looks like until you’re in sight of the end of the project.

Corporate projects have many stakeholders.
They all have a say in what will be done, how it will be done and whether you did it well enough, not to mention conflicting corporate objectives and personal agenda. You can write down what success is in a document or contract and measure against what you have written. That will help a little, but still doesn’t get you a stable and satisfying definition of success. In these complex and uncertain environments you can ask many people what success is and they will all give you different answers, and probably different answers at different times.

Success changes over time.
What would be considered success at the beginning of a project may not cut the grade by the time you end. This reflects the problem of business requirements changing over time while the project continues to work from the baselined plan and is the rational behind quality compromising software developments such as Agile and Rapid.

Defining success a very complex topic and one that I am not able to deal with here except to offer a temporary and simple definition that suits the purpose of these posts: Success is making your customers happy enough to pay your bills and come back for more.

So having called out our definition of success I can now talk about whether marketing for projects can help us get there in my next post.

Sidebar: There are plenty of posts on this blog about quality. If you are interested in the ideas around managing quality in projects you can search, browse or follow this link and read more.

5 March 2007

Marketing Projects: Marketing via Project Management

I am looking at the relationship between marketing and project management. It’s my assumption that applying marketing principles to project management could help projects achieve greater success rates.

In my previous post I took a moment to reflect on what marketing is today, and where it sits in an organisation. The answer I can up with is that marketing is core to what modern business is about.

Today I want to look at how project management supports modern marketing organisations.

These days these internal capabilities that support marketing strategies are usually developed and introduced via projects. Examples include the introduction of sophisticated data warehouses, CRM systems and so forth. Project management brings organisations improved ability to acieve their marketing objectives.

As an organisation transforms through projects it builds project management capability. Organisations with a high project management capability usually run many projects. In order to more efficiently align these projects with business strategy they are often grouped into programmes of work. (De Reyk et al, 2005.)

So projects are tools that are used to achieve a business’s marketing strategies. And those marketing strategies are tools also. they are about the organisation changing to make itself and its products as attractive as possible to customers and potential customers.

Project management brings order and discipline to the change process. Given many organisations often unstructured and non-strategic strategies, project management and programme management can assist in achieving successful outcomes.

Project management is an effective framework for planning and managing change through the delivery of improved business systems, new tools and modifications or organisational structure. These changes are planned and executed with a view to meeting or anticipating customer demands, competitor innovation or other risks and opportunities.

1 March 2007

Marketing Projects: Project Management helps fulfil marketing strategies, right?

I am following up on my suspicion that applying marketing principles could improve project success rates.

So far I have put forward the proposition that projects almost run as businesses these days and if marketing is good for businesses it should also be good for projects.

I have also searched around to see if the idea has already been addressed in the academic world and have been unable to find anything specific to the topic.

With this in mind I thought I should go back and ask the basic question of what is marketing and where does it fit into modern business?

In the 50’s and 60’s marketing was a method of improving a businesses products with the end aim of beating out the competition and selling more units. The basic idea was framed around understanding what the customer wanted or valued and building to their demands.

Things have evolved and in the 80’s and 90’s marketing all but dominated the strategy of businesses. Marketing has reached deep into organisations at all levels, from creating intrepreneurs and internal professional service organisations to developing improved supply chains and CRM systems to acquisitions and joint ventures.

Marketing brings the voice of the customer to strategic planning, and that aligning your value proposition with something that customers want makes your business more viable.

Almost all parts of a large modern organisation’s structure, systems and processes are designed to fit together as part of an overall marketing strategy. Marketing is now core to what these businesses do.

Bert De Reycka, Yael Grushka-Cockaynea, Martin Lockettc, Sergio Ricardo Calderinia, Marcio Mouraa and Andrew Sloper (2005) ‘The impact of project portfolio management on information technology projects’ International Journal of Project Management Volume 23, Issue 7 , October 2005, Pages 524-537

Charles H Noble, Michael P Mokwa, (1999) 'Implementing marketing strategies: developing and testing a managerial theory,' Journal of Marketing Chicago (Oct 1999) Vol 63, Iss 4 pg 57, 17pgs

Christian Homburg, John P Workman Jr, Harley Krohmer, (1999) ‘Marketing’s influence within the firm’ Journal of Marketing, Chicago (Apr 1999) Vol 63, Iss 2, Pg1, 17pgs

Francis Buttle (1996), ‘SERVQUAL; review, critique, research agenda’ European Journal of Marketing, MCB Press, Issue 30.1 pp 8-31

Pervaiz K. Ahmed and Mohmmed Rafiq, Internal Marketing (2002) Butterworth-Heinemann UK