top of page

Software project improvement 

All software and software projects can be improved all the time.

​

The question is, what are the priorities based on concrete technical risks, required investments, available resources and resulting impact.

The importance of facts and figures

My clients usually want to improve software or software projects because they experience challenges with costs going up, missed deadlines, scope creep, recurring bugs and even damaged reputation.

 

Often the causes are unclear and contradictory opinions circulate. The pressure increases on all stakeholders, which leads to emotions, unfounded decision, broken trust, … and it's all downhill from there. 

 

Very often there is a disconnect and even a breach of trust between management and technical staff. This leads to the unfortunate situation that there is doubt about the technical issues and risks, potential solutions, as well as additional cost and time required. 

 

Nevertheless, there is a wealth of technical facts available if you know where to look, and more importantly, if you know how to put it together relatively quickly to get an objective view on the actual state of the software and the project.

 

Additionally, this picture needs to be translated for C-level and board audiences, augmented with cost and timing estimates, and placed in the context of the business strategy. 

Keeping it in-house

With almost 20 years of experience in these types of situations, I know that lasting changes only happen when they are done in-house. â€‹

​

As such, I work closely together with the key project members and management in order to do a software audit. We reuse knowledge that is already in your company and complement it with facts and figures where needed. 

 

It is important to note that all new knowledge, processes, tools and results are transferred back to the project, the people and your company. 

Software project audit

A software audit is conducted together with the relevant and available people. This is a mostly technical exercise with the purpose of analysing facts and figures about the software and the project.

 

Depending on the situation the following is assessed if available: the source code and its version history (e.g. Git); user stories, issues and bugs (e.g. Jira); infrastructure setup and code; management of (open source) third-party libraries; architecture and documentation; information security and technical and organisational measures; and so on.

 

These elements are both qualitatively and quantitatively analysed. For example, the source code is assessed with respect to its quality, but statistics are also collected about lines of code, development effort, commits per day, etc. Another example is user stories. These are reviewed with respect to their content, but numbers about lead time and cycle time also provide interesting insights. 

 

Furthermore, the findings can be used to assess processes, people and responsibilities, in combination with a selection of interviews and observations. 

Experience and references

In addition to the about section and the testimonials, I'd like to point out that I have assisted companies and other instances with the above for almost 20 years. See also the national registry for experts.  

 

Some of my clients are not in the position to give a testimonial due to confidentiality, but if you'd like more references that are relevant to your situation don't hesitate to contact me

​

Don't hesitate to give me a call (or book a call) if you have any questions. We can discuss approach, timing and a cost estimate, without any obligations. And if I cannot help you, I probably know someone who can. 

bottom of page