Tips For Analysts On Software Projects

/

Every software project is unique and there’s no guarantee that the approach or strategy that works well for one project will work for another. There are however, some basic guidelines business analysts can adopt to add value to software projects.

According to the book, Analysis and Design of Information Systems by Arthur M. Langer, most software development problems are based on two fundamental issues:

  • Trying to solve the wrong problem; what we think is the problem is not always so.
  • The solution to the real problem is often easier than it appears to be

To address these issues, here are some universal tips every analyst should remember:

1. Evolve Requirements
Do not expect to get all your requirements from users. Users will never be able to define 100% what they want. Adopt an iterative process that will allow requirements to be fine-tuned as the project goes on. Early prototyping and constant feedback from users during the project can help clarify requirements and guide the development process.

2. Don’t Impose Change
Work within the environment and take the reality of the organization into consideration. Users should be the ones deciding what degree of change they are willing to accept. As an analyst, you may come up with an idea that you believe represents the right course of action; stakeholders should however, be the ones to decide which course of action they are ready to take. To achieve this, adopt a realistic approach that does not mandate a drastic cultural change in the environment. This will reduce or eliminate any resistance down the line.

3. Assess Stakeholders
In addition to conducting stakeholder analysis, know the skill sets of users before engaging with them. This would allow you to set up a plan for approaching each user category and defining the kind of questions to direct at them. Understanding the technical capabilities of users guides the analyst on how to phrase interview questions and identify who else, in addition to the identified stakeholder, may be required at the interview. This is where a pre-meeting comes in - this is a short meeting for gauging the stakeholder's technical competence and level of interest in the project before the main working sessions are organized. 

4. Don’t Ignore the Politics
Assume that every situation is political. Software projects are not complex on their own; it’s people that make them so. Don’t ignore the political environment or the constraints it imposes. To do so is to invite failure. A key question to ask stakeholders is this: “Can you give me some perspective on potential departmental or personnel conflicts that may occur during this project?”. You may not get all the information you need at once from one person, but the feedback you get over time, is bound to improve your knowledge of any existing politics.

5. Pilot Before Rollout
Always set up a pilot environment. This will provide useful feedback on both the effectiveness and shortcomings of the delivered product, which can be addressed before full implementation.

6. Plan Realistically
Ensure that your project plan is realistic. Always make allowance for iterations between analysis, software development/configuration and testing. The back and forth between analysis, development and testing is inevitable and should be captured in your plan realistically. This will ensure that resources are available when needed and that everyone believes in the practicality of the project plan.

Reference