Think software design and development.

Think software design and development; There is one common denominator in all the digital transformation projects that I have participated in; project sponsors want to get to the development phase as fast as possible.

For some reason, the perception of developers writing code gives them the sense that the project is progressing, while the truth is that involving developers too soon can create significant and costly delays to the project.

That is why it is essential to have complete and thorough documentation and design phases. And there is one particular aspect of both steps that need special attention: the people.

In our documentation process, we pay special attention to what we call users and roles. A project manager can fall into the temptation of lightly describing the users and their functions. After all, when designing a software project, the language is common for almost all the stakeholders. When we talk about a project lead, everybody understands the role of that person in the process and what software functionalities are needed to support his job.

But a good documentation process needs to go further.

• What is the personality profile of the project leads?

• What is the technology profile of the project leads?

• What is their typical daily schedule?

• Where are they going to interact with the system?

• What type of hardware do they have available?

All these questions help a software designer understand behaviors, and the key to success in any digital transformation project is in the intersection of functionality and behavior.

As Tim Brown says in his book Change by Design, “For design thinkers, however, behaviors are never right or wrong, but are always meaningful.”

We recently discovered how behaviors affect technology projects.

One of our most significant digital transformation projects was introducing automation and digital tools to a staff augmentation company in the energy sector.

We developed a very robust mobile app for resources to report their timesheets with labor codes and comments. We created a web-based tool for the Team Leads to approve or reject the field workers’ timesheet lines. From there, the system automatically would create timecards in the payroll system and invoice lines in the ERP. It is a great system that saves a lot of time and effort for a company that needs to manage multiple projects with minimal overhead.

We achieved the integration with the Payroll system through a double way rest API between both systems.

Not long after we went into production, the accounting team started noticing duplication in the employees’ timesheet lines. Sometimes it was one, then two or three, even four duplicates!.

The bug was tough to replicate because it had no symmetry and no common factor between the different instances. It happened to different users on different time periods, during different times, and various hardware.

The root cause started revealing itself when we had multiple data points, and we began to see one commonality: the speed of approval.

Initially, we designed the system to allow real-time approval of the timesheet lines.

If a project lead clicked on the approval button, the system would let them know in a matter of seconds if the approved line was successfully transmitted to the payroll system. The process took an average of 3.75 seconds from the moment the button was clicked to the API call report. Not bad.

But the reality is that in the context of this operation, Project Leads have dual roles as supervisors and technicians in the projects they are leading. This dual role gives them very little time for administrative functions. Add to that the fact that most of them live Monday through Friday in hotel rooms near the job site and spend hours going back home. They use old computers with old operating systems provided by the client for security reasons and connect using hotel wireless services.

The result of these factors is a behavior that affects the performance of the software. Project leads were clicking on the approve button an average of once every 2.6 seconds and sometimes multiple times to approve the Team’s timesheet lines as fast as possible.

This is not a technical problem; it’s merely a behavior not identified in the documentation that led to a design choice that seemed appropriate without that piece of information. If we had taken the time to understand the circumstances, we would have introduced a batch process like the one we used to permanently fix the problem.

An excellent digital transformation project should always design around the people. Everybody participating in the project, clients, users, project managers, and sponsors needs to commit to letting the documentation and design phases run their courses without rushing into development.

If you follow this advice, you will shorten your projects’ delivery time, and you will reduce the cost of development, which is usually the most expensive cost of a custom development project.
software