Want to make an immediate positive impact on a new project, and demonstrate that you are a high-value team member with heaps of initiative? Then read on to discover 7 key questions which can help you get there.
For any IT Professional, the first day-to-week of a new project assignment can be critical to project success, the team’s perception of your competence, and consequently, to your own immediate and longer term professional success.
The objective of this article is to answer the question “What are the most important things I need to know, discover and do in my first week on a project?” While the author’s own area of expertise, and hence the focus of this paper, is on the Business Analyst role, this paper in principle is broadly applicable to any IT professional taking on a new assignment.
The Business Analyst role I am discussing is interested in modelling a business, its systems, and possibly the system’s components. These models may be a study of these domains as they exist today, or as they are envisaged for the future. The goal may be to understand and improve a business process, often but not always through the application of technology solutions. The textual and/or diagrammatic models created by the Business Analyst are often employed as a method to convey business and/or system requirements to the people who must envisage and implement technical solutions in support of those requirements.
This paper aims to put into writing the approaches I currently employ, usually implicitly, and largely successfully, in an attempt to succeed in, and make a success of, the projects in which I am involved as a Business Analyst, especially within that critical first two week period.
An Engagement Process
Imagine yourself assigned to a new project in the role of lead Business Analyst. Where do you begin? Do you look to the project manager to provide the guidance you require, with respect to approach, methodology and tools? No – their expertise is in getting the right person for the job, to deliver outcomes – in this case, that person is you.
You will need to bring to the project a kit-bag of methodologies, tools and approaches, and rapidly determine which ones should be applied to allow you to do the job that is expected of you.
And what is expected of you? Your project manager will expect you to drive requirements elicitation from the client. The client will expect you to quickly understand their business, and help them to understand how a business and/or technical solution will deliver to them the benefits they are seeking. If it is a technical project, the technical team will expect you to deliver the logical definition of the system which is to be built, in a way which will allow them to develop and deliver the technical solution which meets the client expectations.
So, what methods, tools and techniques do you need in your kit bag, and how do you determine what to take out of that kit bag for a particular engagement? The following series of steps should begin to point you in the right direction.
1. Situational Assessment – Where am I?
On entering a new engagement, determine the status of activity
- Is the engagement / project definition clear? Is there a clear, well communicated project charter, vision or the like, defining engagement scope, purpose, goals, constraints?
- What phase of the project lifecycle are we in?
- What phase of the software development lifecycle are we in?
- If project is in-flight, what methodology, if any, is being used? Is this helping or hindering? (see points 5 and 6 for more detail).
- What is the health of the project? (On time, on budget, quality, client relationship, team morale)
If there is no clear documentation answering these questions, write one. Not ‘War and Peace’, but a one page summary of what you think the answers are.
Ask the manager, and some of the team leads to review and critique your summary. You’ll improve your understanding, and may find you have created a valuable resource which might be used again and again.
You may also find you stir up a hornets’ nest if various parts of the team currently have different views with respect to what the project is all about. Better you find that out now, however, than in a year’s time when the project fails because the basic charter was unclear.
2. Team Assessment – Who are we? Are we all here?
Are all key required roles present and filled with competent resources. The following is one list, although the exact titles and break-up of roles may vary according to the project management and software engineering methodology being applied:
- Project Manager
- Lead Architect
- Lead BA
- Lead Developer
- Lead Tester
- QA Role
A single person may hold more than one of these roles on a given project, however, a clear and distinct delineation of roles if preferable.
In addition, key client stakeholder roles should be identified and the people in those roles should be named. In Scrum projects for example, the key client role is the Product Owner – the person who owns and has final say on requirements and their relative priority.
3. Knowledge Assessment – What do we know?
What is the existing level of defined knowledge in the three modelling domains?
- Enterprise / business
- System
- Component
Explicitly identify what that information is, record it, and make an initial assessment of quality / usefulness.
All three domains are important, and should be modelled and documented at least at a summary level.
In my experience, business analysts typically are involved in defining and documenting the first two domains, and much less commonly in the third domain – which usually falls under the ‘design’ heading, and is in the realm of the technical design team. So focus your assessment on the first two domains. Refer to the sidebar for more definition on the purpose and approach to modelling these two domains.
To illustrate the importance of both the business and system domains – a project with system requirements modelled to a great level of detail may result in a well defined and built product. However, without the enterprise model, that product may have very poor fit with actual business needs, resulting in poor client satisfaction with the delivered product – even though it may have been delivered with zero defects against the specification.
If you have never heard a client say “You delivered exactly what I asked for, but not what I needed!”, then you have thankfully avoided this scenario up until now.
4. Role Expectation Assessment – What am I doing here?
What are the expectations which the client, the engagement management and other stakeholders have for your role? Do expectations go beyond the boundaries of a BA-only role (eg into architecture, designer developer etc)?
People’s expectations of your role may vary widely, based on their past experience, articles they have read, the specific needs of the project and many other factors. It would be wise to identify a few key stakeholders and ask them exactly what they expect your role to contribute to the project.
If you find that expectations do go beyond a BA role as you understand it, consider carefully whether or not you have the skills to operate in those additional domains (eg Solution prototyping)? If not, identify this early, and work out strategies to address any gap areas. This may involve cooperation with other team members, and/or escalation of the issues with project management.
5. Method Selection – What is our approach to doing this job?
If a solution engineering / requirements management methodology has not been explicitly selected and implemented, make your own assessment of which methodology would best suit the client and solution environments.
This assessment may be constrained by client or management, but as the business analyst you should make a judgement on the best methodology to implement from your perspective and make a recommendation. This will depend on your own knowledge and expertise.
Traditional waterfall / structured approaches are common. Agile (iterative and incremental) methods such as SCRUM and XP may or may not replace or be incorporated into or wrapped around some of the more traditional approaches.
Why is this important? Business clients are increasingly sophisticated when it comes to expectations of process maturity in software development teams. Failure of a software project team to identify and implement some form of recognised process is tantamount to negligence, and provides the team with little recourse should the project begin to stray outside of expected quality, timeframe and cost parameters. The process does not have to be onerous – it can be relatively lightweight (eg Scrum) – but should be fit-for-purpose according to the size, value and criticality of the solution under development.
If you are not experienced or qualified to make such an assessment, at least raise with your project manager that you would like to understand the requirement management approach you are expected to follow. If the manager has not and cannot define one, then you should at least provide a template demonstrating how you plan to document the requirements, and get management, client and development approval on your approach.
As a Business Analyst, you are unlikely to be accountable for the project management methodology, however, it is worthwhile confirming for yourself that adequate aspects of project management methodology have been put in place – especially areas which directly interlock with business analysis responsibilities, such as scope management. If not, initially raise any concerns directly with your project manager.
6. Methodology Customisation and Tuning – Are we applying the tools in the most effective manner?
The methodology selected under the previous point should be customised to the specific engagement.
The BA should drive selection of the work products (documents, deliverables) and approach taken in their area of responsibility, in conjunction with other stakeholders.
Some generic classes of BA work products are described later in this paper.
The minimum set of work products which deliver the stated project objectives should be determined. The correct set is one where additional work products take further time for little additional value, while fewer work products would not adequately meet project objectives.
For example – if a well documented use case meets client needs for requirements definition, and development and test needs from a specification perspective, then there may be little or no additional benefit realised through the production of additional requirements artifacts (eg System Requirements Specification). This is not an Agile-only approach, although Agile methodologies do tend to favour more ‘lean’ approaches to documentation.
7. RAID – What are the biggest dangers, and how are we addressing them?
Risks, Actions, Issues, and Dependencies.
Determine all of the in-flight risks, issues and dependencies which impact the project, and the actions in place to manage and address them.
If there is no formal or existing approach to managing these four key categories of information, raise with your project manager the need to implement a formal approach (and start tracking them yourself in the interim).
Some of the points mentioned here may seem to be presumptuous with respect to the relative responsibilities of the project management and business analysis roles. It is my personal experience, however, that:
- Project managers tend to easily fall into spending much of their time managing the client more than they do the details of the project. This is an important part of the project manager’s role, but can leave something of a vacuum with respect to detailed management of solution scope.
- By taking initiative on some of these areas, especially around BA approach and methodology, you will increase team, client and management confidence in your ability, whilst also allowing you to set your own direction with respect to the best way to identify, model and manage requirements.
- A good project manager will appreciate assistance with keeping control of project scope and issues, and will often look to a capable business analyst to assist them in doing so. A less capable project manager might perhaps be threatened by such initiative, but in the long run you will still be doing the right thing by the client, yourself and your team in attempting to raise the standard in these key areas.
It has been said that you have two weeks when starting on a new project, before the problems you have inherited become your problems. Using the approaches mentioned above, you will have the tools to identify many of the problems which might cause the project, and your career, harm, and as a result you will be able to address those issues sooner than later. In taking such initiative, you will quickly establish yourself as a high value team member, and take control of the management of your own role at the same time.