The phrase "project audit" sounds threatening to some, while for others these words have a sense of formalism and bureaucracy. No one particularly likes to have their work checked, especially if the person checking it is an outsider. Most often we've heard the word audit in the context of checking financial or accounting statements. Furthermore, in the past few years, many have encountered an IT security audit. But I'd like to tell about the audit of business analysis processes for one of our company's projects. This service may also be useful to your project.
About ten years ago, I first served as a project auditor in terms of business analysis. First, we created a document that regulates the work of a business analyst — the procedure for developing and managing requirements. Such an audit, for the most part, consisted of checking compliance to these requirements within a specific project. But as part of the audit, I could make recommendations that were not directly provided for by formal documents, but rather based on common sense and my practical experience. Thus, I combined audit and consulting. Based on these results, a plan was drawn up, and then the implementation of this plan was checked as part of the next audit.
A distinctive feature of DataArt is that our company's culture welcomes diversity, and there is no need to strictly follow formal rules and procedures, including in business analysis. Simply put, we welcome flexibility and try to avoid formalism. Instead, professional communities develop recommendations and templates that projects can use as they are, or adapt or come up with their own. Therefore, our audit usually involves consulting assistance from an expert and is initiated by the PM or DM. Since we do not have pre-planned audits (except for information security audits), an expert is involved in the audit when there are persistent problems in the project. The list of such problems is fairly standard:
- Delays in preparing requirements for the start of the sprint.
- Constant changes in requirements and/or their priorities.
- The team and/or client are not satisfied with the quality of the requirements.
But the reason for doing an audit may be not only difficult problems, but also positive changes, such as, for example, the team has grown, but the old approaches/processes are not scaled.
BA audit case
In 2018, one of the DMs from our finance practice asked me to help sort out some problems that had accumulated in a promising project that was experiencing growth sickness. The team had grown, the communications process had become more complex, and the above-mentioned problems had become more frequent and stronger. DataArt suggested that the client conduct an audit to solve the problems.
The audit started with the fact that I was invited to a daily stand-up, where I was introduced to all the team members. From that meeting, I remember most of all the phrase spoken by the project manager: "Meet Denis — our expert business analyst, but he won't be with us for long." Looking ahead, I can say that this prediction did not come true, and after the audit, I successfully joined the team and have been working in it for more than two years. After a quick introduction to the team, I conducted a series of interviews with key team members: the PM, team leader, QA lead, and business analysts. At the same time, I started studying project artifacts: requirements, diagrams, release plans, and descriptions of the current process. After getting the overall picture, I moved on to a detailed analysis of current processes:
- How the work of business analysts is planned and tracked.
- How requirements are identified.
- The format in which requirements for development and testers are given.
- How the project's knowledge base is maintained.
- What tools and approaches are used.
At a certain stage, I had the opportunity to participate in communication with the client, and to observe the process of interaction with the client.
Process
As a result, I identified both global problems (lack of a project vision, lack of formulated problems that the project aims to solve, road maps, etc.), which were caused by the fact that the project had outgrown the boundaries of Proof of Concept and had become a strategic initiative, as well as a number of smaller problems. For example, the BPMN notation was used for business process modeling before writing detailed requirements, but it was not used entirely correctly. This may seem like a small thing to some, but imagine that you take words (which are analogs of graphic elements in the notation) and begin to arrange them in any order in the sentence, even forgetting about punctuation marks. What did this mean in our case:
- Models can be interpreted in multiple ways.
- Actual errors in the model caused by incorrect use of notation elements.
- Unnecessarily complex diagrams that are difficult to read and understand.
- Problems in the process description.
All this led to the fact that the models did not fully perform their function, misleading both business representatives and the team that needed to automate these processes. The problem was that even though the client was the initiator of the idea of using notation, they were not experts at using this notation. We organized internal training for the entire BPMN team, plus a number of training sessions for client representatives. And this once again emphasized that DataArt is ready to provide a wide range of services. The situation was similar with writing techniques for standard requirements. Creating templates adapted to the needs of the project allowed us to further improve both the speed of our writing and the quality of the requirements.
Very often, recommendations that work well in theory are broken when they meet up against harsh reality. Therefore, after analyzing and making recommendations, we conducted workshops to test the proposals for feasibility in the project conditions.
Report
Based on the results of the audit, a report was generated that included:
- A description of the current state of the project in terms of business analysis of related team activities.
- A list of identified risks and problems, and recommendations for their resolution or mitigation.
- Suggestions for changing the processes for working with requirements.
- Specific recommendations for tools and templates.
As for suggestions for improvement, some (for example, the creation of a long-term plan for the development of the platform), required considerable effort and took a year to be implemented.
Already during the audit, it became clear that some of the risks and problems that were based on the human factor, could not be solved by us. But we can take them into account and try to mitigate the consequences.
The results of the audit were presented to the client, the procedure for implementing the proposed changes was discussed, and responsible persons were appointed.
Here are some examples from this plan. (click on image for larger version)
Epic Decomposition Process (click on image for larger version)
Requirement Preparation Process (click on image of larger version)
Results
Later, I had the opportunity to see the results of implementing the recommendations. According to a rough estimate, about 70% of the planned improvements were implemented. The project team began to expand even more, all while overcoming most of the identified growth problems.
Summing up, I would like to say once again that audit/consulting not only improved the quality of business analysts ' work, but also removed development bottlenecks, which allowed the team to practically double in size in the future (for example, the number of business analysts on our side has gradually increased from two to six), and for the project to develop dynamically. Of course, not only did the audit lead to such results, but it also contributed to the overall success.
Author: Denys Gobov, CBAP, PMI-PBA, PhD
Denys Gobov is a Head of BA Community at DataArt, founder and trainer at Art of Business Analysis. He has more than eighteen of experience in the area of system and business analysis. Denis has taken part as a senior/lead business analyst in a number of large projects in different domains: finance, transport, HR, e-goverment, etc. He has been playing an active role as a Vice President of Ukraine IIBA chapter. He was recognized as the best professional in the area of “Business analysis” in the All-Ukrainian independent award “Ukrainian IT Awards” in 2013 and 2016. You can reach him at artofba.com or Linkedin.