I have taken responsibility for software delivery that connects customer needs, developers' work and the operations that follow. When several disciplines and systems are involved, I work with realistic plans, visible dependencies and timely decisions so the result can be used and maintained after handover.
At Modified Solutions, many assignments were project-based. I took part in clarification, planning, prioritisation and follow-up, and I took the conversation when scope or expectations changed. With avecdo, the perspective also included the product's continued operation: a new feature had to work alongside existing data processing and customers who were already using the service every day. Those two kinds of work have taught me that a plan must describe both what we build and the reality it has to fit into.
Make dependencies visible while there is still time to act
A delay does not always originate inside the development team. A clarification from the customer may be missing, or access to another system, or a decision about data and responsibility. I want those kinds of dependencies out in the open before they turn into a deadline crisis. That requires ongoing conversations with the people who own the decision and an honest assessment of what the team can deliver.
The mobile service process we built for an international company is one example. The app had to work for employees out in the field, and information had to flow on to the customer's system. The technical integration was only one part of the delivery. The workflow, the data and the people who had to make decisions on the customer's side also had to fit together. I owned the customer dialogue and led the development, so the different parties could work towards the same goal. See the specific case.
Plan with room for reality
I have used a simple capacity practice: as a starting point, we booked around 80 percent of the developers' time for customer work. The rest left room for the unexpected, bugs, coordination and learning. It was a leadership decision not to promise the same hour away twice. The practice is described in more detail on the page about capacity planning.
At delivery level, this means I would rather talk openly about a changed priority than let a team carry a plan that no longer fits. When something new comes in, we need to know what has to wait, who decides that and what the consequence is for the customer or the product. I am used to having that conversation with both specialists and decision-makers.
Quality also means handover and responsibility
A piece of software is not finished for the business just because it can be demonstrated. It has to be usable, monitored and maintained. My background in hosting and operational responsibility means I ask early who will detect a problem, how we can fix it and who the customer talks to if something goes wrong. When an incident occurs, I am happy to handle the communication, so the specialists can work on the cause.
In a larger organisation, I would start by getting an overview of the existing teams, their dependencies and the decisions that most often slow the work down. Then we can agree on a rhythm for prioritisation and follow-up that gives management an honest picture without creating unnecessary meetings for the developers. I have experience with software delivery and people leadership; the specific way of working has to suit the organisation and the people in it.
Contact: kontakt@tomc.dk · +45 299 297 67