I would start with a project initiation meeting:

• This will bring together the key stakeholders

• The areas covered will be a mission statement, high level objectives, identify all stakeholders, clearly define scope (both what is in and out)

• Discuss what sign off from this stage will look like

• Agree timeline, next steps, follow up meetings

Follow up

• These will depend on how complex the project is

• One-to-One meetings with each of the key stakeholders

• Group meetings with teams reporting to key stakeholders

• Workplace shadowing with key workers

• As-Is process mapping business experts (brown paper & post it notes, then transferred to Visio)

Iterative Process

• Even on the most simple project, say a simple BI report, it is important to continually replay findings back to the stakeholders to ensure my understanding is inline with theirs.

This very much depends on style of the organisation I am working for:

• A lot of what I have done has been the traditional requirement definition, title, unambiguous requirement definition, explanation with examples, test scenarios, name of originator and MoSCoW rating. Both functional and non-functional

• Use case diagrams

• User Stories

Every project is different

• I have worked on projects that have sent the requirements out for solution providers to submit tenders which have required evaluation.

• On small projects I have worked with developers and solution architects to come up with proposals

• On some projects, typically reporting, I have used wireframe techniques to produce mock up designs using tools like excel and access

• On large package implementations I have attended vendor workshops to help identify fit of existing package to requirements and how to handle any gaps.

I believe the Business Analyst should see the project through to implementation and roll out. As well as the requirements and solution selection I have been heavily involved with

• Sign off of system testing against requirements

• Supporting the business through user acceptance testing

• Implementation and roll out planning

• User training

At the beginning of my career I started as mainframe developer and at one point ran a small team of developers producing Virtual Reality applications using C and a games engine. That was some time ago I now look at the technology platform as an enabler for the non-functional requirements of a project. I prefer to leave the detailed technical work to the specialist confident that I have a sufficient knowledge to understand the implications of what I am being told by the technical experts.

One question I had recently was how would I approach a requirements gathering exercise that was timeboxed to thee months.

• I would sit down with the PM and agree the key milestones to reach the required deliverable

• This would allow a simple project timeline to be developed so that it could be agreed what activities would need to happen in each week

• This would result in a plan that we could track against to ensure I was on target to hit the required date

• It would allow key milestone meetings to go into the diary up front

• I am comfortable using tools like MS Project to do this sort of activity