
Bill Aitken
Bill Aitken is Head of Business Systems Development at QA. This role provides business direction and ownership of QA’s Business Analysis, Systems Development, Software Testing and Enterprise Architecture curricula.
Bill is an experienced lecturer, author, speaker and consultant, having delivered programmes and course in all industry sectors. This extensive hands-on experience coupled with a background in education has made him well-known and highly respected in his field.
Bill is a State-qualified teacher and Chartered IT Professional and has successfully undertaken training and consultancy to hundreds of learners. He currently works with a team of highly experienced lecturers and consultants helping organisations excel in all Business Systems Development.
Previous posts
- Posted by Bill Aitken
- on 15 February 2012
Projects vary enormously in content, timeline, resources, aims and objectives. But one thing remains constant – if the project does not somehow contribute to meeting the business strategy, it is doomed to failure at some point in its lifecycle. This is where business analysis (BA) comes in. Using the range of tools it provides, the alignment of the project to the business becomes more defined and requirements engineering more grounded in the domain of what is needed rather than what is wanted. The Business Analyst is arguably the key role in ensuring that this is so.
Business analysis is often
poorly leveraged within companies and Practitioners are often
situated within IT departments instead of the wider business.
Getting the best out of the dark art requires that the BA is
involved at strategy level within an organisation to enable them to
help formulate company strategy. In that way, they affect
all projects. From the specific
point of view, they are vitally important in helping to create the
business case and feasibility studies. The project then
starts off on the right foot.
I rarely meet anyone these days
who does not accept the fact that requirements capture is probably
the most important phase of a project. Poorly-written
requirements lead to systems built on a foundation of sand and we
don't have to look very far to see the consequences of this.
The newspapers frequently declaim against the vast sums of money
spent on such disasters in the NHS, Government, military and so
on. It's also a truism that the only point of an IT system is
to support the business, yet we frequently see evidence that the
end-users were poorly consulted. The BA is the key role here
to ensure that their requirements are properly recorded. And
something more - projects almost always have a political dimension
to them. Business analysts can negotiate between seemingly
intractably-opposed viewpoints to come to a level of agreement and
compromise. Without it, projects can be stalled and even
cancelled.
It's often a surprise to many
that the BA is more of a creative role, rather than a technical
one. It is in business analysis that the current system,
functional and non-functional requirements come together to form a
vision of the future system, free from the issues which plagued the
old one. That particular cake can be cut up in many different
ways and a well-trained, talented BA can offer many options of
varying cost, performance and functionality. Thus, the design
and development of the eventual choice is based on options which
meet the users' needs and conform to SLAs, legislation and business
objectives, making eventual testing easier and with fewer
re-writes.
In short, business analysts and
the skills/techniques they offer, are all about bringing accuracy
into those early phases of the project particularly affected by the
most imperfect of machines - the human being. Their skills in
bringing order from a chaotic mess of conflicting, ambiguous and
just plain wrong requirements allows the project to point in the
right direction from the start. Further, their work at the
strategic end of the company allows them to have horizons wide
enough to bring lessons across from one project to another,
reducing time, cost and error.
What a pity so many of them are restricted to modelling
processes.