Project methodologies traditionally get a lot of air time with consultants and IT groups. However it can often turn into a discussion that is actually more focused on the SDLC (software development lifecycle). In many situations the SDLC becomes a proxy for project management, and this is usually when the organisation does not have either project management or IT as part of it's competencies.
Project methodologies are varied, from the Project Management Institute's PMBOK (truly a body of knowledge rather than a methodology per se) and PRINCE2, to custom methodologies developed in-house. And of course consulting organisations (Deloitte, Accenture, Abeam, etc) will jump at the chance to implement their "proven" methodologies - for a fee. Project methodology should focus on managing a project from start to finish, delivering a unique business result.
An SDLC should instead focus on specific tasks and deliverables required to meet a business need through the use of IT. IT requires a combination of discipline and flexibility or adaptability in order to deliver successfully.
In organisations that don't understand the objective of a project management methodology, the IT department is often seen as the defacto project management function, since that's where the investment of time and money into "projects" is most obvious. And in these situations, the project management function often becomes simple coordination of meetings around the SDLC. As a result the business becomes alienated by the lack of transparency and a significant gap in understanding between what the users want and what they get.
Project management needs to be given attention separately to the IT function, and then linked into both Operations and IT.
Wednesday, 16 January 2008
The role of business analysts
A topic that's been on the table over the past couple of weeks is the definition of a Business Analyst, and their role and responsibilities within the company.
In IT vendors this is fairly straightforward. The Business Analyst (BA) is the link between the users (the business) and the System Analysts or Designers (depending on the company you come from). They need to understand the business area (e.g. life insurance, pensions, A&H), be familiar with the terminology and the operational processes (clerical procedures), and be able to translate this into language the techies understand.
The BA also needs to know what, how, and when to challenge what the users say. When they do this well they are often called a Consultant, Business Consultant, or Functional Consultant.
In insurance companies, the term Business Analyst often appears to be translated into "documenter" or something similar. A number of BAs I've seen are not contributing actively to the improvement of this business, but rather just producing paper on behalf of others who cannot do it themselves.
However there are many, many situations where the insurance company would benefit from a challenging mind. The natural trend is to accumulate additional process steps and the complications and inefficiencies that result. A challenging mind in the BA would improve things no end.
Of course the balancing factor is the relative ease with which an external BA can challenge compared with an internal BA who needs to maintain a long-term relationship with the business users. The BAs who can achieve this are the golden geese - hold on to them!
In IT vendors this is fairly straightforward. The Business Analyst (BA) is the link between the users (the business) and the System Analysts or Designers (depending on the company you come from). They need to understand the business area (e.g. life insurance, pensions, A&H), be familiar with the terminology and the operational processes (clerical procedures), and be able to translate this into language the techies understand.
The BA also needs to know what, how, and when to challenge what the users say. When they do this well they are often called a Consultant, Business Consultant, or Functional Consultant.
In insurance companies, the term Business Analyst often appears to be translated into "documenter" or something similar. A number of BAs I've seen are not contributing actively to the improvement of this business, but rather just producing paper on behalf of others who cannot do it themselves.
However there are many, many situations where the insurance company would benefit from a challenging mind. The natural trend is to accumulate additional process steps and the complications and inefficiencies that result. A challenging mind in the BA would improve things no end.
Of course the balancing factor is the relative ease with which an external BA can challenge compared with an internal BA who needs to maintain a long-term relationship with the business users. The BAs who can achieve this are the golden geese - hold on to them!
Sleek MacBook
Nothing at all to do with financial services, but all the buzz in the office today has been around the new MacBook Air as described here on MacWorld. I will be looking out for it to arrive in the Apple store in Ginza.
Tuesday, 15 January 2008
The promise of SOA
Apparently Accenture has rejoined the school of "state-the-obvious" and realised that Service Oriented Architecture (SOA) is not delivering on the hype.
The industry continues to focus on a single technology at a time, without considering the wider architectural context. On it's own the SOA paradigm moves one step towards and answer, but without considering the components in a business context, it is a futile exercise that does little more than line the pockets of the consultants.
Interestingly the Computerworld article refers to the CIOs that tell Accenture that they need to work more closely with the business. So true. SOA needs to be viewed as an enabler rather than an end in itself. IT must get back to focusing on business relevance. It is interesting to note the number of articles (like this one from Harvey Nash) that point to the reducing influence of the CIO in corporations.
Let's go back to the basics and focus on the endgame instead of technology for the sake of technology.
The industry continues to focus on a single technology at a time, without considering the wider architectural context. On it's own the SOA paradigm moves one step towards and answer, but without considering the components in a business context, it is a futile exercise that does little more than line the pockets of the consultants.
Interestingly the Computerworld article refers to the CIOs that tell Accenture that they need to work more closely with the business. So true. SOA needs to be viewed as an enabler rather than an end in itself. IT must get back to focusing on business relevance. It is interesting to note the number of articles (like this one from Harvey Nash) that point to the reducing influence of the CIO in corporations.
Let's go back to the basics and focus on the endgame instead of technology for the sake of technology.
Introduction
From time to time there are interesting articles published, both in print and online. This blog focuses on issues relevant to the role of IT in the financial services industry, specifically Life Insurance.
Subscribe to:
Comments (Atom)