Petyo Dimitrov: 9 Criteria to Assess Your Project's Maturity & Improve

In this talk, Petko Dimitrov presents a systematic approach to assessing software project maturity through nine specific criteria. He begins by defining project maturity, emphasizing the importance of stability, architectural quality, and the ability to reliably operate in production. Petko shares his experiences as a software architect, discussing indicators of maturity and how assessments can lead to improved project outcomes. He details each of the nine criteria, including security, code quality, deployability, and testability, while providing real-world examples to illustrate their significance. Ultimately, Petko stresses the need for effective communication of assessment results to stakeholders, ensuring that the insights lead to actionable improvements.

Welcome back, folks. Hopefully you enjoyed your little break and are ready to sink your teeth into our next subject because we've got Petko Dimitrov who's here to talk to us about assessing projects and how to improve them. Petko? Thank you very much. Hello everyone. Thanks for the introduction and thank you very much for joining my session. My name is Petko Dimitrov and in this talk I will

share with you nine criteria you can use to assess a project's maturity and identify how to improve it. I've been working in software engineering for a while now and in the last 8 years or so I have worked as a software architect. And as a software architect one of my responsibilities is to assess projects either because we start working on them and take them from a different

supplier or just as a regular post check to see the state of that project and over time I accumulated different indicators that are common for projects and projects are good with one some projects are not good with in another and I combine them group them into these different criteria and organize them so I can share them first with my colleagues in the organization so they can improve

and reuse them and at some point a few years back I also started sharing it with other interested interested people architects etc. as we are doing in this session now. So what we'll talk about is first what I understand by speaking about maturity of a project, uh, how one can assess it. Uh, then we'll dive a little bit in the nine different uh, criteria, uh, where I

will mark specific indicators without aiming to cover everything in each area because then it will take much more time than the one we have allocated. Uh, and at the end I'll also share with you uh, how you can organize and communicate that information uh, either with your teammates and or stakeholders uh, or with the client as it is often in my uh, uh, experience. Uh, and I

will also share throughout the talk and especially at the end some lessons I have learned from doing that in the last several years. So, first what do we mean when we talk about uh, uh, technical maturity? A friend of mine has a small daughter and recently he was telling me that they watched Tom and Jerry together and he realized he's getting old uh, because he was constantly

thinking why is that mouse tormenting Tom basically. Uh, and yeah, with age uh, we become more to uh, but in the context of a software project when I speak about maturity I mean that the project is stable, is using uh, uh, good technologies, has a proper architecture, is reliable and in a nutshell is a good bedrock for uh, continual continual continual operation in production and to also

build new functionalities and develop it further depending on where it lies in its life cycle. So, this is our focus. Uh, why does that matter uh, to us? Well, I will share with you three examples when we do such assessments that are kind of more ad hoc like not as part of just regular check-ins or new projects that are starting. One of the popular reasons is that

you get a serious production problems uh like on outage or some kind of other kind of incident, which is a common driving factor to invest a little bit to see where we lie on different aspects and more importantly to see how to improve. Another reason is if there's a big upcoming release, like a lot of things have been accumulated uh and uh the the project determined that

as a sufficient risk to invest in proper assessment and yeah, identifying key improvement aspects. And the third common one is uh negative feedback, either from stakeholders or from clients, uh users of the of the solution, which can be a driving factor. And by thinking about those things proactively and early on, ideally we can mitigate those before they even come to pass. Like we don't get negative feedback

or we don't get uh risky huge deliveries and ideally no production production incidents. And like not serious production incidents are inevitable anyway. Uh so, uh why nine criteria? You might uh ask yourselves. Uh there is uh this uh I think psychological uh study uh that was uh summarized in what's called Miller's Law, stating that a person can keep in their short-term memory around seven things, plus minus

two things, depending on their condition, age and other uh factors. Uh so, in a short answer, I opted for nine uh because I wanted to load test your uh short-term memory, basically. Uh but uh on a more serious note, um the the reason there are nine is first, there are multiple aspects in a software project that one could think about. And even now with nine criteria, we

don't get it exhaust like it's not completely exhausted. It doesn't cover everything that one might want to cover for a for a software project. Uh and uh more importantly, even though they're quite a lot, like nine is not a small number to manage, uh usually in practice we don't focus on all of them. Uh as I'll talk in a in a minute, uh at the early stages

of a project, we focus on what is most important, either based on our experience, the state of the project, or the priorities of the stakeholders. And ultimately, we end up with less than those items in the list. Yeah, so this is more of a bucket list of criteria from where you can pick and choose the items that you want to to use in the project. And now

we can have a look at the high-level criteria themselves. So here we have security, code quality, several abilities, so deployability, testability, and operability. Then we have integration, cloud, processes, and finally third-party libraries and dependencies. I will dive into a little bit more details into them in the in the coming minutes. Why they're ordered in this way is kind of arbitrary. As I mentioned earlier, this order depends

strongly on the project, like in its state on its state, its targets, and some other factors that may may influence it. But I ordered it in a common way that usually we prioritize them unless there are other factors coming in. So one thing that is clear is usually one needs to pay a lot of attention to security since it's in the top left corner, while third-party libraries

integrations are kind of more for projects with a lot of resources and yeah, needs to to invest into them. want to give you here a few examples. Like recent last year we had a project we were assessing which was entering a market with a clear competitor, like clear competitor there, and they expected to have a large number of users and maybe even kind of sketchy competition going

on. So by having a look at the project, we first identified that their security was yeah, satisfactory uh for for those environments. And also that it makes sense to have a more robust security in order to protect their competitive aspects that they want to compete with. And also since they expected bursts of users coming in, their cloud capabilities. So, in that project we prioritized the security aspect

and the cloud capabilities with a few more in the second degree and a few others in a least priority category which were just marked and not invested when doing the analysis. Another project was a startup company where they had just finished a particular iteration and they had procured financing for the next round, like for the next iteration. And there what we saw was first that the first

iteration was done rather hastily. So, the quality of the code was not sufficient. And also they haven't invested a lot in operability of the solution. Like a lot of things were done manually and ad hoc depending on the needs. And on the opposite side they had quite a big road map and a lot of functionalities that they wanted to build and extend on top of the platform.

So, as a result there we focused on code quality and operability as aspects. Well, for example for example they didn't mind that much integration because the the same team was handling all the parts. And yeah, there were some issues in the integration in their API design and some other aspects. But it was not as critical in the short run rather than being able to develop new new

capabilities on top of the platform. So, here are some examples of considerations you might have when you are at this early stage of assessing the Now, we'll talk a little bit more about the methodology. And this of course as I mentioned earlier can vary. Like if you want to assess your own project, you're more of an insider. So, some of the things will not be as is.

Well, if you're a consultant external to the project, you need to kind of gain a little bit more understanding that is not present by default. Uh so, I will mention both perspectives in my in my presentation. Um when starting in the first fully first phases, which I named here kickoff meetings, we need to explain the process and also its importance to the different parties that are involved.

uh as I mentioned before, it's quite important to emphasize and clarify the scope of the assessment. How deep we will go when assessing the project, which also applies when you are assessing even your own project, because we all have deadlines, we have time frames which we need to fix to. So, we cannot spend all the time on everything. So, when clarifying the scope, we will see are

we doing just kind of a regular checklist or are we diving into the source code of the project and doing more extensive sessions with the team. Uh and also at this stage we see what parts to be included, like what criteria to emphasize more and also what components of the project. Like maybe the project is planning to rewrite the mobile application, so they will not invest in

analyzing it since it's already on the chopping board. the identifying the key criteria usually doesn't happen right away because from my perspective, I need some time to understand the project and to get uh details about it and the the other part to get to know the the team that is working on it. And usually it happens in a follow-up meeting, like not at the exact start of

the project. Uh we also need to take care to align with the timeline. Like one recent project I had had a big delivery coming in, so we agreed if we find any critical issues with the security aspect of it, those are were directly sent, so we were not waiting for a a final organization of the data sharing and proper communication to give the the team more time

to address those things since they were more important for their success. Usually at the beginning we also need to request documents and access in reverse I usually like to share documents as well with the team because the topics we are talking about are not some hidden knowledge or some cutting edge AI based research but it still it usually happens that either this information that gives you context

about the methodology that is being used and the different criteria and their indicators is first useful for semi-technical people which might be your project manager or some other position in the project and also even for technical people they might have an idea about those things but since they dive they're deep in their day-to-day responsibilities and yeah work they might have not thought about it. So having these

materials at hand will help them be more productive in our sessions together. And last but not least we want to to ensure the participation of key team members. This this could be from the business side but these are also like technical people, senior engineers or architects. We need them to have the necessary time to have sessions with and with clear agendas and targets so that we can

be successful. Without participation from the team members themselves such an assessment is usually superficial and yeah doesn't doesn't bring the desired effects. When we're reviewing materials first as I mentioned we have documents and projects here lie on the spectrum. Like some projects have very extensive documentation especially if they're in an industry which have has regulations and requirements. And there you have the project of a problem of

being swamped with documents. While on the other side, there are some kind of startup projects that haven't had time to invest yet in documentation. So, everything is very sporadical or even not written itself. Um but here I have mentioned some key things usually we want to have a look at or request from the team to summarize for us or even if nothing is there to discuss it

during face-to-face like peer-to-peer meetings. Uh so, those are the specifications, the project plan with its timeline, the high-level architecture and the selected technologies, information about the infrastructure, information about the APIs or some kind of documentation they have, the details about their development process. Sometimes a user guide is useful resource in in this context. Uh we might have a look at the Agile board and the tasks and

even join some kind of Agile ceremonies. But this is usually if we're doing longer analysis that takes over a few months rather than a quick several week check of the project. Uh then for the code base, effectively we cannot check it ourselves manually. So, we use automated static code analysis tools. Sonar is a good example that covers different technologies, but we can use a linter or a

language-specific analyzer as well. Um and those tools are not absolute like the findings that they discover align on a spectrum. Like some of them are quite useful and definitely need to be addressed. While others are ignorable and definitely should be ignored. But using such a tool gives us a common understanding and kind of a high-level view of the of the project itself and ensures that we do

some kind of due diligence. A lot of the projects we we check or have some uh switch static code analysis that is being done. So, we just have uh take a look at it and kind of uh cross it off from our list. Uh but, others don't, in which case we take over doing that analysis provided of course uh documentation is signed off and we have access

to the code base. The selective manual code review is more specific because uh yeah, our time is limited as well. So, usually either we focus we focus on some specific parts basically, not on the whole code base. Uh usually, what we do is either the client points us towards a problem an area where which has problems before, as I mentioned for example production problem uh recently, or

new functionality that was developed and they want to ensure that uh their new developments are improving and following uh best practices. Uh but, even if that is not present, usually uh automatic code analysis tools can give you some kind of high-level metrics, like something's like a high heat map that shows components which are with cyclomatic complexity or with good or low cyclomatic complexity, uh and which are

used a lot or are bigger, which allows us to handpick particular examples to check them and provide insight based on it. Uh exploratory testing is also a tool uh uh that I use uh where I it could be just exploring the functionalities of the application to understand it better, uh or even doing some preliminary penetration testing if security is identified as an area uh for the Okay,

so when you go about uh as I said, we have nine criteria and each of those criteria has a lot of indicators that determine uh try attempt to determine uh the maturity in that area. Uh so, what we use is something like a checklist. Here I'm sharing just an extract from the checklist. Uh and in the QR code and in the materials uh in the presentation itself,

I'll provide the link to it so you can download it and use it for your own uh assessments and yeah, adapt it to your own needs. please note that the checklist itself is always evolving. With with each projects we assess, we make minor modifications, add indicators, remove them, or change how we evaluate it. So, this is the current snap snapshot I took from from the from the

knowledge base. Uh, so what we're seeing here is a kind of systematic approach where we have the criteria. So, this in this case is integration criteria. And for each of the indicators, we're assessing binary. Is it fulfilled or not fulfilled? So, it could be a green or red effectively. Uh, of course, not everything is binary, but we try to generalize it a bit and to add sufficient

details in the description. Like those details are also useful if later on we do a follow-up assessment after a year, for example, to to refresh the context for the reviewer. Once we have these indicators marked, a general evaluation is made, which is usually made some kind of based on some kind of ranges. Like if a sufficient number of items are checked, the thing is considered satisfactory. It

starts with not satisfactory, then it goes to good, and ideally the target of excellent. Uh, but those are not always just quality quantity based. There's also a quality aspect to it. So, one indicator might be more heavy than another. So, we could adapt the final score depending on that when needed. And this checklist is basically something that we go through throughout the analysis phase. So, we might

review particular aspect of the project, have sessions with the team, and then populate the the the checklist. The population, especially if the team is mature and the assessment is not very deep, can be done by the team themselves and then we discuss it together. Or, yeah, it could be done by the architect that is doing the the record. Uh, and now we'll have a We'll at the

some specific indicators for the different categories. And again, these are not exhaustive, but they serve first as a checklist. And additionally, based on them, we identify specific recommendations, which can result in tasks being added to the backlog of the team so that they can address them down the line. So, first we start with security. And here, considerations that need to be checked are common things like has

the infrastructure been properly hardened? Is there trade audit tracing of changes? How detailed that audit tracing is? Are we validating input data? Do we use encryption of the data in transit and at rest? And with the gradation of those aspects that are being covered, we get a higher score or a lower score effectively. But this doesn't mean that if we miss something very critical, like for example,

if we keep our passwords plain text or something like that, we we might not get a critical recommendation that needs to to be addressed. What helps us in the security analysis is the OWASP list. There's already well-maintained list of common vulnerabilities, which like injection, cross-site scripting issues, etc. So, we use that in context when we have discussions with the team or when checking key parts of the

application itself. Some static code analysis tools have vulnerability detection, which can be useful. Like for example, Sonar reports on stuff like that. One thing that one thing that pops into my head is it will easily identify if you're storing credentials, like infrastructure credentials in your code, which is a general bad smell. When doing penetration testing, we we can use some kind of a proxy like the ZAP

proxy, explore the application, and it automatically exhausts different vulnerability attacks and prepares a report for us, which is quite useful. But usually, to be honest, for penetration testing, we are if we do it, it's usually early indicator and we emphasize taking a penetration test analysis separately like by a dedicated team with a specialized expertise since this is a quite deep topic. But it helps for the initial

analysis to give a general look at this to give an idea of the of the state of the project. Vulnerabilities can also be assessed for yeah, exploitable versions and another aspect of the list is when if the project is properly assigning least privilege to its infrastructure, dependencies, etc. Because in some small projects, it's a common pattern of just having an admin account and sharing admin privileges to

the users. While yeah, a more segregated approach is definitely a best best practice in the field. Moving forward, code quality is an evergreen in software development and of it depends on the project itself. I mentioned earlier the example with the startup that wanted to grow. So code quality is important because they need to be able to maintain and easily understand and extend the code base in the

near future and hopefully the far future. But for another project that is a more legacy project with stable code base that has switched to a micro service approach where new development is actually separate from the main code Code quality might not be as critical to them as an indicator. What we do with code quality is again we use automatic code analysis which gives us an overview of

the project as I already mentioned. And also gives us nice visuals which are always useful for non-technical Also one thing to that is useful is to have a look what what is done with technical debt. Like uh uh is it uh tracked explicitly? Uh because some some projects don't do it. I mean the dedicated tasks opened and put in the backlog. And what percentage of that uh

uh of work is allocated to technical debt? Because if it doesn't uh if the team doesn't track it and doesn't have uh time to address issues, this is a big red flag. And yeah, we can make a lot of uh suggestions and recommendations, but yeah, ultimately that aspect needs to be Uh coding standards being well defined. Yeah, using common standards like from Google or or other organization

uh is a good practice and kind of unifies the codebase, which is nice. And of course, reviews and pair programming can help with that. Uh pair programming is a little bit divisive uh with at least the the customers that I have worked with. It usually requires kind of convincing and it's more challenging to see uh the value in it uh the value in it. Uh but uh

yeah, peer reviews is from my perspective like a must is a is a minimum if uh yeah, more allocation cannot be achieved. Uh in the uh employability side, we're looking into how the uh project can easily and efficiently be deployed on uh production. Uh because uh for example, one of the projects we had um it was very mature with a lot of processes, documentation, the code quality

was good, but uh they even had already moved to the cloud uh in a previous initiative, which was nice, but they didn't invest in deployability, which resulted in new versions being deployed within days uh even weeks instead of hours. Like their use case didn't allow like very fast uh deliveries, but it was still too slow down uh preferable for the business. Uh and when assessing these indicators

that we're looking at are the presence of the continuous integration and deployment pipelines. Uh ideally, they should be tracked as code and maintained as first class citizens of the of the Um, also a good indicator is if the built and deployment uh, pipelines are separate. Are they tracking artifacts in a repository in a version manner? And uh, if they have uh, uh, a ways to avoid drifts

in their uh, environments. Like changes creeping in into the the environment so to have some kind of environment parity. Uh, which uh, yeah, is easily achieved if they testing infrastructure uh, as code and have proper automation. But for other projects it is a challenge and it uh, can cause unexpected production issues as as we all know. So those are common indicators when we're uh, looking into the

deployability of the project. Uh, testability focuses on understanding how easy how already tested the project is and how easy it is to find issues and bugs uh, earlier on. Uh, and which is also uh, cheaper to fix like the earlier we find it uh, in the software development life cycle the better. Uh, and here we focus on the coverage like what level of coverage there already is.

How much has the team invested in uh, the testing pyramid? I mean uh, what uh, how much test they have on as end-to-end tests at the top or how much testing they do on unit test level at the bottom. Uh, because you the pyramid is known like we all know it but you'll be surprised that projects which kind of don't emphasize enough on this. Sometimes stick only

with one of them and miss benefits by combining multiple mechanisms. Performance tests are also uh, an important thing to check especially if the project has uh, public users and high performance Uh, and ideally you want those things to be automated and already integrated with the software in uh, with the CICD solution that is used in the in the project. Because otherwise they usually tend to be stale.

Like some clients, they do a performance testing initiative which is kind of a one-off, and then yeah, the thing falls into disuse and is not actively maintained. On the operability side, we are checking how easy it is to maintain the solution in production. Uh and yeah, in DevOps there are a lot of practices which we can employ to that end, like having standardized and centralized logging and

configuration management, ensuring that health checks are checked and you have proper dashboards and metrics, having a process of root cause analysis whenever an issue happens in to ensure that yeah, lessons are learned and yeah, things are not missed in the hurry of the of the incident. Um also important is to ensure that when an outage happens, the solution recovers, like is able to survive the restart, reconnects.

Uh and that you're getting proper notifications and timely notifications to address the issues and react to the to the problem. So, these indicators being present help with the operability solution and make it easier to to maintain. Uh on the integration front, we are basically interested and this are the last the final group it could be more dependent on the project itself and its specifics. Uh the integration

checks if the project is easily integratable by other components or integrates well with components. So, it is bidirectional to to an extent. And here, of course, having an API using common is what we are expecting, investing in having an API documentation that is easy to understand and ideally is automatically generated is beneficial. And also from a architectural perspective, a balance between synchronous and asynchronous communication. Uh because

uh yeah, synchronous communication is simpler, but usually for uh some integrations and larger scale projects, uh this um uh this uh having a synchronicity, a messaging platform can make it more more decoupled and easy to uh scale and grow in the long run. So, this is usually a good suggestion if the the project over solid. Um uh and uh finally, it's important for the project at a

minimum to track their non-functional requirements. Like, what are their expectations of uh usage, availability, and other such indicators. Uh and ideally, they should be automated and tested and integrated with the uh CICD tooling, but even if not, as a minimum to be documented and known and taken into consideration with new development and changes to the platform. Uh core capability uh is something that uh became uh ubiquitous

in the in the last uh uh years, uh and usually our clients are in the cloud. So, it easily uh able to uh ensure that they have uh virtualized their hardware. Uh but on a more advanced note, uh uh making sure that the application is uh cloud friendly will allow them to uh better benefit of the uh scalability of the cloud uh and to uh yeah, usually

there is a benefit in the in the at least early phases of uh ownership, like the cost of ownership of the Uh and here, what we're checking is if proper containerization is used, is the application conforming uh to the 12-factor criteria for cloud-native applications, which uh provide guidance uh in that direction. Uh some projects uh are highly scalable, uh so they can easily scale horizontally, but uh

they're, for example, just lacking the elasticity aspect. Uh so, they don't adapt to it uh elastically and there's some easy win there just with some configuration to give them more benefits to the operability aspect of the project. Uh it is also nice important and this one is kind of in the middle between fault and integration uh to employ fault tolerant design. So, here are the common uh

design patterns popularized by microservices like having circuit breakers, uh bulkhead pattern being used, uh or even more simple things like ensuring that your API calls have proper retry and timeout configured uh will make you the application more robust and uh easy to maintain in Um usually uh larger scale projects also uh need to have a disaster recovery plan being done at least on a plan level, ideally

also with some kind of dry run being performed, but that one is more common for uh industry verticals that are more heavily regulated. On the processes side, we are checking if the team uh the project and the team uh have the methodology in place to better and easily easily develop the project uh going forward. Uh and these are common things and most projects have them, but usually

at surface level, it is good to check them to make it sure something is not missed like project management, version controlling, uh usage of uh and presence of some key documents especially for the small scale projects which overlook uh documentation in their efforts. Uh and yeah, this is something to to consider. And last uh in the list which is the least uh important uh aspect, but in

some projects could be of importance is how they're treating their kind of third-party dependencies or systems that they use in their overall architecture. Uh like uh here we're interested if they have up-to-date dependencies which can uh be automatically checked, if they have an upgrade process in place. Because some projects start, have specific dependencies, and then skip on upgrading them due to lack of time, lack of automated

testing, or or or something else. And that becomes very difficult down the line, especially and can be a problem especially if there are no internal tools which are accessed publicly and those exploits can be effective can have an effect on the overall solution. Some clients which are more in some industries also need guarantee that they comply with open source requirements, but this one depends. Like some clients

don't care about it at all. But for for some industries this is a must. And finally, it is important to make sure that the critical components solution have a future in a nutshell. Like either they if they're a commercial project, they have good SLA and they have the necessary support. Or if they're an open source project that it is alive and well. One example I can give

is we had a project maybe four or five years ago which due to a set of factors had cornerstone element in their architecture, something that was nearing its end of life. So, being able to identify that and remove them into the from the future architecture made development and yeah, the happiness of the team itself much better in the long run. So, investing some time to look into

it from a strategic perspective can be beneficial to the project. So, having done all of that, you basically have had sessions with the team and you have looked in all those aspects of those different criteria and have collected a lot of information. The last part to consider is how to present those results. And here my recommendation is to have a standard template. I'll share some highlights of

how I'm doing it myself, but having a template gives you something professional to have as a deliverable to the client, which they can then take to their bosses and have you in using strategic discussions and other aspects, but it also gives you consistency when you're doing it and may my simplify another person onboarding another person to help you with those activities down Uh regarding the content themselves,

there are several highlights. One is uh the first we'll emphasize on two of Uh the first one is the one-page summary uh and the other one is the technical recommendations. Uh besides that, sometimes in the report I include a technical overview of the project, like their business use case, the high-level architecture, technologies, and some infrastructure information, uh which is uh not as useful for the technical team

itself because they have that information, but could be useful for semi-technical people to have it summarized in one place uh and also can serve as a reference, like when we're referencing something in the recommendations down the line, having the extra context may be Um uh I usually like to document the constraints of how the assessment was done, which is more if you're doing it as a consultant.

Like if you if it's already your project and you're part of it, that's not as important, but defining the constraints, like what was the availability of the people that you needed, uh what was the was the scope reasonable to the allocated time, and did you have proper access to the required materials uh is important because sometimes the client will be a very active at the beginning and

be very interested, but then they couldn't uh give you those uh required those uh preconditions for a successful analysis, and tracking that and documenting that is uh beneficial to the uh to the overall initiative. And in the appendix, we include uh reference materials, like an explanation of the methodology, uh the information sources that were analyzed, and any additional materials from the review, like results static code analysis,

uh from license checks, dependency analysis, performance penetration test reports, and stuff like So, when we are doing the one-page summary, a thing that I have seen work very well is hitting this kind of a high-level holistic overview of the project. So, you put the different in these nine dimensions, and you track two things: the actual level, which you can see here is the orange line in the

middle, how much is covered. And the skill itself is not satisfactory, satisfactory, good, and excellent, like some kind of gradations But additionally, you're also tracking the expected level. And here is where an architect can give and an experienced person can also give their knowledge and expertise. Like, you align that expected maturity with the project specifics, with its plans, and also your expertise of of doing that that

down the line. So, for example, for demonstration that I have shown here, we highlighted security, which was not on a desired level, and yeah, a few other aspects. Well, for example, processes were not determined as important in the third-party software systems. This one is very beneficial to non-technical people because they it gives them a better and more accessible understanding. In this one-page summary, usually we summarize the

information in a this kind of a table format, which has the Here I have listed two of them, for example, for an example. It gives details with highlights of the positive and negative things that were seen during the review. And also adds some form of business impact. Like, for example, this project had issues with security, which were analyzed during some exploration and penetration testing. And their impact

was that with enough effort, a sensitive customer information can be obtained obtained and extracted. It was not easy to do, but it was quite manageable to achieve. additionally for more visual representation, what we are tracking here in this is what is the current level. So, for example, security was analyzed as satisfactory because they had a lot of things in place, but they had those gaps and exploits

as I mentioned earlier. And also we are tracking the target. So, for example, we may determine that security is satisfactory, and if it was an internal application, this satisfactory security would have been enough if only, for example, employees of that organization use it. And then the overall status would have been green. So, expectation and reality match. But in this case, since we are targeting excellent levels, we

mark it as an orange. Like this is as area that will need improvement. While code quality, due to the large gap and deviation between expectations and realities even highly higher more intensively colored. Finally, we have the recommendations. Those are the technical things intended for the team. And here again, we usually arrange them in tabular format, but it could they could directly be opened in the project management

system of the client itself as well. What is important for them is to be numbered because they will be referenced during meetings and other activities. So, having that is a must. They are grouped into the different They have detailed descriptions and clarifying details because sometimes the analysis is done and other and then there is a follow-up in 3 months. So, having the proper details in place is

important. maybe the most important part is to have them prioritized. Like because ultimately such an analysis usually yields a few dozen to a hundred items, even a little bit above sometimes. And not everything will be realistic to to be addressed. So, what we do is we we yeah, emphasize based on our experience the higher priority ones so the team can focus their attention on those topics. And

as a conclusion some lessons from my one common thing to to keep in mind is to tailor your information to the audience. For high-level management the one-pager the high-level summary brings great results while for technical people you need to have those details in order for them to be useful to the team and you need to go into that level of specificity. Additionally visuals usually grab the attention

like at the beginning we didn't have the radio chart and we struggled to convince the the stakeholders and to understand them but giving it more visually shown helps without like here is an example I have shown an example heat map which easily shows separate parts of of this example application that need attention. Third one is to engage the key stakeholders early and to understand their pains during

the sessions. Here we had an example where for a client me and another organization were doing assessments on different parts of the application but the difference was that in the sessions I had with the team I involved the architect technical people and business people to clarify to help understand their project and to discuss recommendations and an approach to them as part of the process. My colleagues however

from the other organization they did that kind of separately and when they presented the results at the end without kind of a buying and common understanding even of their intentions yeah, the results were not to do to their liking basically and when you're doing that it's important to understand kind of the mid-term goals of the particular stakeholders. One unsuccessful story we had was a place where we

made a very detailed analysis how the client can address a particular problem they have and have had for a while, but did not but we were missing that the key stakeholder required kind of faster results. They needed something within a 6 to 9 month period, while the plan that we prepared for them for a refactoring and optimization was a 2-year plan, which didn't fit their needs. So,

this was a good lesson for me to make sure that the time frame of the recommendations fit the expectations of And the next the final thing is to make sure you balance the static analysis with the dynamic part. What I mean by static is having a fixed checklist where you are specifically just going through the checklist. While the dynamic one is exploring and discussing with the team

their needs and requirements. You cannot do both to the maximum and need to balance them to in your work. And yeah, one other point as a reminder is to not forget to save time for the follow-ups that are necessary. Usually discussions afterwards, more prioritizations, roadmaps might need to be created, and those things require time. In conclusion, with this information I tried to give you an exhaustive and

systematic approach to how you can evaluate projects and give you a little bit of an external perspective if you want to do it for your own project, as well as a way to target the results properly so that they land and you can achieve your goals, so that you ultimately are not as the person in the cartoon that cannot and is ignoring their problems with with their

maturity. So, thank you very much for listening. If there are any questions, I would be glad to to address them. All right, fine. Fantastic. Thank you, Petio. Yes, folks, So you do have any questions, quickly slam them in there as we are short on time, so we want to make sure that we get as much out of Petio as we can. Uh I've got kind of interesting

one straight away. Like you know, you had the the nine criteria points. Which one do you think, if you had to choose one, is the most important? The most important one as I mentioned earlier, depends a lot on the project and its specifics, but ultimately security I would put first. Like this is why I put it on the top left corner of my my my list because

usually the issues there issues there have very critical impact, like very large and serious impact to the organization. But again, this might depend and there are definitely situations where operability or deployability will bring you better But yeah, if I have to choose one, I'll pick that one. Okay, that's fair. Um I don't think we've got any questions coming in right now and I'm just conscious of the

time cuz we've got to set up a discussion panel for the next section. So, uh what I'll say is, you know, if people want to reach out to you, I think you do have your details in your profile. There we go. Boom. Fantastic. Superstar that he is. So guys, if you want to reach out to Petio, if you have any follow-up questions, there is his email. Uh

feel free to connect with him on LinkedIn. Uh but Petio, absolute pleasure to have you on, my friend. I think uh we'll let you get on with your day and see you soon. Enjoy the rest of the conference. Bye-bye. Goodbye. Okay, folks. So, uh just a short break, probably 5 minutes and then next up, we've got pretty interesting one actually. We're going to have a discussion panel

going on with several members of the community to talk about the intersections of leadership. Pretty exciting stuff. We'll see you in a sec. Woo!