Here is the second segment of the three-part series where Profinit’s CEO, Tomas Pavlik, offers recommendations on how to avoid serious mistakes when searching for developers for your team or when shopping for custom software development when there is a serious shortage of qualified software professionals in Europe.
3rd Recommendation: Delivery management is the key
I am convinced that the success of a software project depends much more on the process called delivery management than on the length of lists of abbreviations like XML, UML, PHP, HTML, etc. in the CVs of the engineers working on it. Delivery management is perhaps more of an art than a process, an act that requires a fine balance of many ingredients – business requirements, technology, hard financial and deadline constrains, the expertise and skills of individual developers, the professional development needs of team members, Peter’s mood after breaking up with his girlfriend, how long it takes to make a coffee using the company coffee machine, and many other factors. Delivery management positions, both on the side of the supplier and the contractor are usually filled by select members of middle management. They are a precious species that must combine seemingly contradictory skills:
- Delivery managers must be very capable software engineers with experience and professional authority, capable of understanding the details. At the same time, they have to be able to see the big picture.
- They are able to organize work for others. They themselves work systematically and transparently and stand behind their word.
- They can motivate people and care for their team, whether there is an HR department or not.
- They are respected and valuable partners for business customers. They are skilled communicators who can pass on information from the business to the developers without distorting it.
Do you have such delivery managers in your organization? Can you find them on the job market and separate the drivers from the hitchhikers? If the answer is no, I suggest turning to a professional software house and checking its delivery management proficiency with its customers.
4th Recommendation: Let us step over the limits of your line organizational structure
When working on projects for customers, we often encounter barriers between their internal organizational units. These barriers then hinder the work of external partners including software firms. What I am referring to are situations where we are delivering custom software for several departments of the customer’s company. For us as a supplier, the project is managed by one delivery manager and there is one team of developers with flexible resources that can be directed where needed at the moment. Thanks to the skills of our people, we can also change their roles on the project (analyst, developer, tester, etc.) when needed. Our clients often cannot take advantage of this flexibility, as their departments are incapable of coordinating their priorities in a way that would permit the full and optimum use of our team’s available capacity. Quite the contrary, the work proceeds in waves—there are moments when we search in panic for any available hand to douse the fire no matter what it costs, followed by slow periods when some staff sit on the bench waiting for work. This scenario can be avoided, and all parties benefit if some simple agreements are put in place.