4 Tools for Finding Improvement Ideas for Your Project

Before answering the question “Where do I get ideas to improve the project processes,” let’s figure out if any improvements are necessary at all. Maybe things work properly already and there is no room for improvement?

If the customer does not complain to management about the project team daily; if your team is able to deliver within the specified timeframe; if the team members do not leave the project – should we assume that the project is all good and we don’t have to take any steps to improve it for all the members of the entire process?

Actually, we can’t be sure here. Even if customers don’t complain to you today, this does not mean that tomorrow they will not find another provider who delivers the same value as you do, but at a much cheaper rate. If the product is delivered on schedule but with lower quality – this is not a success, but a failure. Also, we can’t say that we have a dream-team when team members are permanently engaged in conflicts with each other instead of doing their jobs. Without proper monitoring and looking for solutions, these issues may lead to significant difficulties in the future.

Continuous Improvement Process for IT Projects

So it is simple for me: when you have a project – you have space for improvements. It’s almost impossible to have things working properly for a long period of time in a constantly changing world. For example, in the case of legislation changes, you need to reorganize your process fast in order to comply with them. Do you remember how it was with GDPR? In addition to product revisions, companies had to rebuild their internal processes to store and process users’ data in a proper and more secure way.

We have a similar situation when any changes happen to a team including planned growth. The team rolls back from the Performing stage to the Forming one, so the Project Manager has to choose another workflow to collaborate with the team members, help them to re-establish their relations, and assist newcomers with integration. The need for reorganization also arises when changes occur on the customer’s side, such as migration of infrastructure to the cloud, purchasing new analytical services, or just introducing a new requirement for reporting. It is critical to adapt to these changing circumstances fast if you want your project to end successfully.

However, even when no significant changes take place, the Project Manager should keep looking for ways to apply their skills for optimization and innovation instead of becoming complacent. One of the main goals for the Project Manager is to set up a continuous improvement framework for the project.

So, how do we know which areas need improvements? At Sigma Software, we encourage our Project Managers to look for ideas and get inspiration from using the following approaches and tools:

Improvement Tool 1 – Retrospectives with Your Team

“It’s uncomfortable”

“Why are we doing this?”

“It gets on my nerve when…”

All of these are hints at opportunities to improve project processes.

Conducting retrospectives regularly is very important since they give the team members a chance to express their concerns.

Here are some real-life examples of how team members’ remarks can initiate considerable improvements in the processes used on your project:

  • Example 1 – Eliminating Unnecessary Effort
    Test Engineer: “Why do we have to write such extensive test cases for every feature?”
    A good question. When our Test Engineer asked it, we discussed if Test Engineers could write short and light-weighted checklists instead of detailed test cases for separate parts of the system. We also asked if our project would lose any quality because of the change. The evaluation of potential risks and benefits for the customer showed that we could make some improvements there.
    After discussing the suggested changes with the customer, we made corresponding process adjustments. As a result we saved about 100 hours per release without compromising the quality of deliveries. We kept test cases in the project process but for critical areas only. Their drafting and maintenance activities don’t take up as much time now.
  • Example 2 – Maintaining the Project Knowledgebase
    Developer: “It was difficult for me to sort through the configuration of this module.”
    Project Manager: “But why?”
    “I didn’t have any detailed instructions. I spent a lot of time trying different options and trying to translate a piece of information from a 50-page guide written in Swedish.”
    “Well, now you know how to install and set up this module, how long will it take you to do this task next time?”
    “One hour. If I don’t forget important nuances that I found experimentally.”
    “Why don’t you write a step-by-step Wiki instruction for this while it’s all still fresh in your mind?”
    The developer created the Wiki instruction so now any team member can set up the module in one hour.
  • Example 3 – Making the Project Progress Transparent for the Customer
    Customer at a retrospective meeting: “I was worried that we would not deliver the release on time. I saw that the team was calm, that the Project Manager was calm too, and all interim deliveries were made according to the plan. But I still didn’t feel confident about the timing. If I had seen some graphs that had shown me that we were sticking strictly to the plan, I would have slept better at night.”
    Project Manager: “Look, we have a release burndown chart on our Jira Dashboard. Let me tell you how it works and let’s check it at our status meetings from time to time.”
    Basically, nothing changed in the process here, we just added some transparency to it. But the customer is calm now.

Improvement Tool 2 – Applying Metrics to All Project Areas Critical for Success

Besides basic metrics that the Project Manager usually applies when choosing a certain methodology for the project (e.g.cycle time/lead time, work in progress, cumulative flow diagram for Kanban), it is worth finding out what’s actually important for the customer and to help them measure these KPIs.

Let’s imagine that we are hired to automate a process. It is logical to assume that the customer would like to know how long it will take them to get a return on their investment and how much better their employees will be able to work using the tool we developed in comparison with manual processes. Measure the parameters in the current process and compare them with the new ones after your solution is implemented. Make a calculation, visualize the result, and let your customer be prepared for the conversation with investors or stakeholders who make the final decision about financing for your further collaboration.

Defects Root Cause Statistics

When it comes to standard metrics, we at Sigma Software collect the Defects Root Cause statistics for all projects. When you determine the key factors causing defects, you will be able to eliminate them.

Below are example root causes for defects in software development and suggestions on how you can remove them.

  • Defect Root Cause: Unclear requirements.
    Suggestion: Focus on improving the quality of the requirements. For example, you can establish standards for requirements writing and testing before the implementation.
  • Defect Root Cause: Affected by another implementation.
    Suggestion: Review your branching procedure and consider introducing gated check-in if you didn’t have that before.
  • Defect Root Cause: Insufficient knowledge of the domain area.
    Suggestion: Conduct workshops, create a project Wiki, or come up with another way to eliminate the lack of domain knowledge as soon as possible that is suitable for your team.

It is important to collect Defects Root Cause statistics rather than just relying on personal opinion to get a clear picture. Based on my experience, when developers name the most common causes of defects on a project, they may miss some important items. When we collect statistics, we sometimes encounter quite unexpected root causes that no one paid much attention to. Of course, some defects are possible in the development process, but an experienced Project Manager can introduce improvements to the process in order to reduce the number of defects and shorten the time needed for their removal.

Focus Factor

One more example of a quite versatile metric is a focus factor. This is a ratio between the time spent on feature implementation against the total time. The focus factor is used to see how much a team is focused on delivering value and not resolving obstacles.

It is expected that as the team dives deeper into the project and the domain and their teamwork level grows, the focus factor increases until it reaches ~0.8. If we observe other dynamics over time, the Project Manager should find issues that distract the team from completing the release goals and remove them.

Improvement Tool 3 – Maturity Checklist

Another tool that we at Sigma Software suggest our Project Managers use for finding areas to improve projects, is a Maturity Checklist. It includes industry best practices and company rules established by our experts over the years. When Project Managers conduct self-assessments according to a checklist, they can find imperfections in their current processes and locate areas of improvement.

Below are some examples from this checklist and consequences of not meeting these rules.

  • Non-functional requirements, including security, performance, availability, and accessibility, have been identified and documented. In addition to the functional requirements (what the product does), it is no less important to gather and document the quality characteristics of the product. Quite often, they are not being thoroughly analyzed and documented and remain only assumptions as opposed to becoming approved product requirements.
    When you get documented non-functional requirements for a project, the team can start planning the necessary types of work and add them to the project timeline and budget. If there are no such requirements at the beginning of the active development phase, this can lead to serious changes during later phases. Changes are always harder and more expensive than creating the right foundation from the start.
  • At the end of each iteration, we show the customer a demo of the work performed. A demo is a great way to make sure we are heading in the right direction on the project.
    If we don’t get regular feedback from the customer on the results of the work done, we risk finding out later or even during the project delivery that we did something wrong or not the way the customer expected. Expensive changes and failed deadlines may be the price for the lack of regular demos.
  • Project information radiators are accessible to the whole team: current project progress has some visual representation (e.g. a burndown chart), which is up-to-date and accurately reflects the current state of the project. EVA cost / schedule performance indicators, burndown charts, various project status dashboards all fall into this category.
    This paragraph indicates that it is not enough to track the progress of the project, but it is also important that all team members have access to this information. When the team becomes collectively responsible for success; its members become more active if they see any deviations from the plan. Also, well-functioning teams can identify and offer assistance and optimization in other areas of the remaining work for the Project Manager.

There are about 100 items in our Maturity checklist and this is just the management-related part. It also covers the engineering, software testing, and configuration management areas. So, after each self-assessment or assessment by internal company auditors, a project team gets a list of to-dos that must be completed for the project to be successful.

Improvement Tool 4 – Knowledge-Sharing Events

I always get ideas from my colleagues who share their know-how and lessons learned at our annual PM Gathering conference and regular meetings of the Sigma Software PM Club. Such meetings are always an opportunity to adopt colleagues’ experience and get inspired by their successes to improve the processes in my projects.

“My dear, here we must run as fast as we can, just to stay in place. And if you wish to go anywhere you must run twice as fast as that.” ― Lewis Carroll, Alice in Wonderland.

Circumstances and both external and internal environments are subject to constant changes. This means that you can implement improvements on a project endlessly. We at Sigma Software do not stop for a minute in this process and continue to surprise our customers with innovative ideas, approaches, and quick response to changes.

Share article: